diff --git a/docs/teilprojekte.md b/docs/teilprojekte.md index 9e6340e..ba8926c 100644 --- a/docs/teilprojekte.md +++ b/docs/teilprojekte.md @@ -128,6 +128,12 @@ Kontrolle: MikroMCP (MikroTik) live · ALLNET = Klickanleitungen · Omada → Co ⚠️ **Rest-Leak bleibt: cudy1 (altes WLAN)** bridged Clients weiter untagged in VLAN1 — nur per Switch-Port-Tag bzw. Alt-WLAN-Abbau (Migration) zu schließen, NICHT auf der MikroTik-Seite. Zusätzlich `st-main rrm=yes wnm=yes` (802.11k/v, behandelt nur das Roaming-Symptom). SSoT-Detail: Memory `project_vlan1_dhcp_incident`. +- 🔴 **Update 2026-07-15: gleiches Leck jetzt auf ap1 vermutet.** `dirtyvader-main`-Clients bekommen zeitweise + `10.40.41.x`-IPs statt `10.40.10.x` — identisches Dual-DHCP-Race-Muster wie oben, aber die 2026-07-06-Härtung + wurde **nur auf ap2** gemacht. Nächster Schritt: gleiche `admit-only-vlan-tagged`-Umstellung auf ap1s lokalen + Main-Radio-Bridge-Ports (⚠️ NICHT `ether2` anfassen — das ist ap1s Mgmt-/WAN-Trunk-Pfad). Diagnose+Fix-Schritte: + `docs/tp19-vlan1-cudy-teardown-runbook.md` Phase A (~30-60 Min). Diese Härtung ist wie die ap2-Variante ein + Provisorium, das mit TP19s VLAN1-Abbau automatisch obsolet wird. ### TP3.2 — WLAN Coverage / P750W-Discovery ▸ ⏳ teil-erledigt (2026-07-02) — `docs/wifi-p750w-coverage-and-map.md` - ✅ **Brother P750W (VLAN30) gelöst:** DHCP-`client-id`-Fix (matcht über MAC → feste `10.40.30.5`); **an ap1 gepinnt** @@ -399,7 +405,8 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung". - **Offen (Modell scharfstellen):** realer Strompreis; ob **FM/DW eigene Nodes stellen** oder Christoph HW hinstellt; Backup-Tool-Wahl (restic vs Kopia); ob heißes Zeug künftig auf ZFS/pve statt Syno. - Abh.: **TP10** (WG-Multi-Site = Transport, Upload-BW-Constraint), **TP14** (Container-Hosts), **TP15** (Node-HW/USV), Muster von **TP16** (reziprokes Per-Host-HA). Kein Blocker für laufende TPs. SSoT dieser Session. -### TP19 — cudy-Teardown + VLAN1-Client-Retirement ▸ 🔜 AKTIV (nächste Priorität, User 2026-07-13) +### TP19 — cudy-Teardown + VLAN1-Client-Retirement ▸ 🔴 AKTIV, HOCHDRINGLICH (2026-07-15: TP3.1-Symptom zeigt, VLAN1 ist ein aktiver Bug, nicht nur Cleanup) — `docs/tp19-vlan1-cudy-teardown-runbook.md` +- ⚠️ **Eskaliert 2026-07-15:** der unter TP3.1 dokumentierte VLAN1-Leak tritt jetzt auch auf ap1/`dirtyvader-main` auf — die ap-seitige Interim-Härtung (TP3.1) mildert das Symptom, **die endgültige Lösung ist hier, TP19**: VLAN1 physisch weg = kein Leck mehr möglich. Das erhöht die Dringlichkeit dieses TPs, verschiebt aber keinen Scope hierher. - **Ziel (Kapstein der Segmentierung, s. Zeile 27):** altes **cudy-WLAN weg** + **VLAN1 als Client-Netz stilllegen** (`defconf`/pool-v1-Client-DHCP zurückziehen). **Nicht** VLAN1 komplett: Switch-/AP-Mgmt (sw1 `.11`/sw2 `.12`/ap2 `.2`) bleiben **by design** in VLAN1 (statisch, kein DHCP nötig) bis zum separaten **MGMT-VLAN99-Cutover** (eigener TP). cudy1/cudy2 = `.41.246`/`.247` (Teardown-Ziele). - 🎯 **User-Gate (Update 2026-07-14): Shelly ist wieder da (kein Blocker mehr) — SwitchBot ist KEIN Prereq mehr, funktioniert laut User erst NACH VLAN1-Retirement (Reihenfolge ggü. 2026-07-13 umgedreht) → wandert in die Teardown-Nachlese.** TP19 damit direkt startbereit. Twinkly nebenher (saisonal). - **Verlorene Shelly — IDENTIFIZIERT via HA 2026-07-13** (User-Hinweis „du siehst ihn im HA"): HA-Device `shellyplugsg3-e4b063e41ab8`, **Modell = Shelly Plug S Gen3**, **MAC `e4:b0:63:e4:1a:b8`**, HA-device_id `7a21e8f3349e6660f8b35974fc989a7b`. **NICHT im 26er-Inventar** (Spare/Küchen-Steckdose, die Christoph beim Einrichten verbockt hat; er nannte sie „küche s20", aber s20=`98:a3:16:7c:5f:ec` läuft sauber auf `.30.206` — Verwechslung). **KEIN AP-Mode, nicht tot:** assoziiert am **Altnetz `elektrosmog.c`** (cudy → untagged VLAN1-L2), aber mit **bogus-IP `10.95.10.206`** (Fremd-Subnetz, User-Fehler) → unrouting-bar, daher weder in VLAN1/30-Sweep noch normal per IP erreichbar, aber **per MAC in HA/WiFi-Table sichtbar**. Der `.219/s12`-Verdacht war Sackgasse (s12 nur saisonal aus). @@ -413,7 +420,7 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung". 4. **Saisonale Shellys s1/s2/s3/s12** (aus): nach cudy-Tod zeigt `sta` auf tote cudy-SSID → beim Einstecken AP-Mode statt Join. **Empfehlung: vor cudy-Abschuss** kurz einstecken + `migrate.py`, sonst AP-Onboarding später. 5. **pve-Interim-IP `.41.100`** (bewusst als Fallback belassen) beim Teardown mit abräumen. Streu-Reste final per ARP/DHCP-Sweep auf 0. - **Teardown-Sequenz (nach Prereqs):** VLAN1-Client-Sweep = leer (nur Mgmt bleibt) → cudy1/cudy2 stromlos/Reset/ausbauen → **SwitchBot floor-lamp via App/BLE auf VLAN30 provisionieren (jetzt erst möglich, Res. `.30.227`)** → ap1 `defconf`/pool-v1-Client-DHCP zurückziehen (VLAN1-Mgmt-Reachability für sw1/sw2/ap2 erhalten) → Interim-Krücken aufräumen (ap2 `frame-types=admit-only-vlan-tagged` = auto-weg mit VLAN1; `st-main rrm/wnm` Roaming-Provisorium neu bewerten) → Inventar/`ip-plan`/DNS `.41→Ziel` final. -- Abh.: **TP14 ✅** (Hosts raus aus VLAN1), **TP17 ✅** (Shellys raus). Verwandt: `project_vlan1_dhcp_incident` (cudy-Dual-DHCP-Leak), **VLAN99-MGMT-Cutover** (Folge-TP, entkoppelt), TP5 (Deny-by-default danach sauberer). SSoT hier + Runbook. +- Abh.: **TP14 ✅** (Hosts raus aus VLAN1), **TP17 ✅** (Shellys raus). Verwandt: `project_vlan1_dhcp_incident` (cudy-Dual-DHCP-Leak), **VLAN99-MGMT-Cutover** (Folge-TP, entkoppelt), TP5 (Deny-by-default danach sauberer). SSoT hier + `docs/tp19-vlan1-cudy-teardown-runbook.md`. ### TP20 — Platform-Datenbank (Postgres Precious-Tier + MariaDB Tier-2) ▸ 🔜 KONZEPT (2026-07-14) — Memory `project_mikrotik_commit_nautobot_gc` - **Auslöser:** Mehrere Dienste brauchen zentrale DB (Nautobot-SoT [TP21], Vaultwarden, HA-Recorder). Grundsatzentscheid statt Nautobot-Insellösung — „wir skalieren schneller als wir schauen können" (User). diff --git a/docs/tp19-vlan1-cudy-teardown-runbook.md b/docs/tp19-vlan1-cudy-teardown-runbook.md new file mode 100644 index 0000000..6dd7968 --- /dev/null +++ b/docs/tp19-vlan1-cudy-teardown-runbook.md @@ -0,0 +1,148 @@ +# 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).