TP5 Etappe 1 pausiert + VLAN1-Restliste aus dem Log-Lauf

Etappe 1 ist aufgebaut und verifiziert, wird aber vor der Sammelphase
pausiert (User-Entscheid): 76 % des beobachteten Inter-VLAN-Verkehrs waren
.41.x-Altlasten. Eine Whitelist daraus haette nach dem Aufraeumen nicht
mehr gegolten.

- Log-Regel disabled=yes, Memory-Logging zurueck auf topics=info
- Kollektor + Logging-Action bleiben stehen -> Wiederaufnahme = zwei Zeilen
  (routeros/tp5-etappe1-pause.rsc dokumentiert beide Richtungen)
- D2 vollzogen: iPhone im MAIN-SSID, .30.201 im ARP auf failed

TP19 bekommt die konkrete Restliste, die der Log-Lauf sichtbar gemacht hat:
prometheus (.20.151) scrapet 10 tote 10.40.41.x-Ziele, .20.105 zieht auf
pve unter der alten .41.100. Umzugsregel 41->20 bei gleichem letzten Oktett.

Der gemeldete Timeout auf .20.100:8006 ist KEIN Firewall-/Portproblem:
pveproxy lauscht auf *:8006, pve-firewall disabled, HTTP 200 in 0,06 s aus
VLAN10 und VLAN20. Notiert ist auch die Fehlerquelle meines ersten Tests -
`timeout` existiert auf macOS nicht und meldet falsch-negativ.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/teilprojekte.md

@@ -205,7 +205,8 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung".
 - Abh.: TP1 ✅. TP3-Abhängigkeit entfällt (WLAN läuft weiterhin über FB bis TP3).
 - **Ermöglicht jetzt:** PVID-Fix in Omada-Profilen (MAIN→PVID10, INFRA→PVID20), untagNetworkIds-Bereinigung, DHCP-Reservierungen für NAS/macmini/pve auf neue VLAN-Subnetze migrieren.
 
-### TP5 — Firewall & Inter-VLAN-Policy ▸ ⏳ **ETAPPE 1 LÄUFT** (Log-Lauf seit 2026-08-14 live auf `crs326-core`) — 📋 `docs/tp5-deny-by-default-runbook.md`
+### TP5 — Firewall & Inter-VLAN-Policy ▸ ⏸️ **ETAPPE 1 AUFGEBAUT, PAUSIERT** (User-Entscheid 2026-08-14) — 📋 `docs/tp5-deny-by-default-runbook.md`
+- ⏸️ **Pausiert am 2026-08-14, bevor Daten gesammelt wurden.** Grund: erst die `.41.x`→`.20.x`-Altlasten aufräumen (s. TP19) — **76 % des beobachteten Inter-VLAN-Verkehrs war genau dieses Rauschen**, eine Sammelphase davor hätte eine Whitelist erzeugt, die nach dem Aufräumen nicht mehr gilt. Log-Regel steht auf `disabled=yes`, Memory-Logging zurück auf `topics=info`. **Kollektor + Logging-Action bleiben stehen** (ohne die Filter-Regel wirkungslos) → **Wiederaufnahme = zwei Zeilen**, s. `routeros/tp5-etappe1-pause.rsc`. ✅ **D2 vollzogen:** iPhone ist im MAIN-SSID, `10.40.30.201` steht im ARP auf `failed`.
 - ✅ **Etappe 1 ausgerollt 2026-08-14** (über Nautobot GC, manual Config Plans; Backups `core-pre-/post-tp5-etappe1-20260814.backup`). Auf dem Gerät: `forward`-Regel `action=log log-prefix="TP5-WOULD-DROP"` am Kettenende, Syslog-Action `tp5syslog` → **Kollektor `10.40.20.18:514`** (syslog-ng-Container `tp5-syslog` auf dem Docker-LXC, Logs `/opt/tp5-syslog/log/`, 10-Minuten-Cron kappt bei 500 MB — der LXC hat nur ~2,5 GB frei). `firewall` ist aus dem Memory-Ring genommen (`topics=info,!firewall`), sonst wäre der On-Box-Log tagelang unbrauchbar. **Blockiert nichts.** Artefakte: `routeros/tp5-etappe1-log-lauf.rsc`, Push-Werkzeug `nautobot/gc-manual-plan.py`. Compliance danach **16/17** (der eine Rotpunkt `ip-address` = bekannte VLAN1-Bring-up-IP `10.40.41.211` aus dem TP22-Backlog, **keine neue Drift**).
 - 🔴 **Fund aus dem Log-Lauf, der Etappe 3 bestimmt: die Regel fing anfangs auch allen Internet-Verkehr** (`out:vlan100`, ~¼ der Zeilen in einer ruhigen Minute, unter Last mehr). Die Log-Regel steht deshalb jetzt auf `out-interface-list="!WAN"`. **Konsequenz für den späteren Drop: er darf NICHT bare ans Kettenende** — davor gehört `accept out-interface-list=WAN`, sonst ist das ganze Haus offline. Diese Whitelist-Zeile ist damit bekannt und muss nicht aus dem Log wiederentdeckt werden.
 - 🔍 **Erste Befunde nach 60 s** (Rate nach Einengung ~166 Zeilen/min): **76 % des Inter-VLAN-Verkehrs ist `vlan20 → bridge`, also INFRA nach VLAN1** — ein Monitoring-Host `10.40.20.151` scrapet ~10 tote/alte `10.40.41.x`-Ziele, HA `.20.105` zieht auf `10.40.41.100:8006` (pve unter seiner **alten** VLAN1-Adresse, real `.20.100`), `.20.107` auf `10.40.41.10:8080`. **Das ist TP19-Material, das TP5 gerade sichtbar macht.** Weiter: `vlan20 → vlan99:8728` (MikroTik-API auf branch/ap1/ap2 = **der Management-Pfad selbst**, muss in die Whitelist, betrifft D4), `vlan20 → vlan30` (HA → Drucker `.30.5:631`, Shelly, Nuki `.30.244:8080`), `vlan10 ↔ vlan20` (Synology Drive `6690`, Apple-Continuity `udp/3722`).
@@ -508,6 +509,12 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung".
 - 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 ▸ ⏳ WEIT FORTGESCHRITTEN (Live-Sweep 2026-07-16: VLAN1 faktisch schon fast leer) — `docs/tp19-vlan1-cudy-teardown-runbook.md`
+- 🔍 **Konkrete Restliste aus dem TP5-Log-Lauf (2026-08-14) — VLAN1 ist nicht leer, es wird noch *aktiv adressiert*.** Der Log-Lauf zeigte, dass **76 % allen Inter-VLAN-Verkehrs** aus VLAN20 nach VLAN1 (`out:bridge`) geht, obwohl dort **nichts mehr antwortet** (alle Ziele im ARP `failed`/`incomplete`). Verursacher sind Konfigurationen, die nie nachgezogen wurden:
+  - **`prometheus` (`10.40.20.151`, NAS)** scrapet 10 tote Ziele: `10.40.41.109:3000` · `.126:9443` · `.127:80` · `.147:5678` · `.149:3000` · `.152:3001` · `.153:9093` · `.154:9100` · `.159:6333` · `.23:80`.
+  - **`10.40.20.105`** zieht auf `10.40.41.100:8006` = **pve unter seiner alten VLAN1-Adresse** (real `10.40.20.100`).
+  - **`10.40.20.107`** auf `10.40.41.10:8080` (NAS alt).
+  - 📌 **Umzugsregel: das letzte Oktett bleibt gleich, nur `41`→`20`** — belegt für grafana (`.109`), vaultwarden (`.127`), Portainer (`.126`). Für `.23/.147/.149/.152/.153/.154/.159` existiert **kein** laufendes VLAN20-Gegenstück (anderswo oder tot; `alertmanager` ist seit TP14.1 als kaputt notiert) → diese Ziele gehören geprüft und dann aus Prometheus entfernt, nicht umgeschrieben.
+- ⚠️ **Kein Firewall-/Portproblem** (2026-08-14 geprüft, nachdem beim Umstellen ein Timeout auftrat): `pveproxy` lauscht auf `*:8006`, `pve-firewall` ist *disabled*, keine iptables-Regel, kein `/etc/default/pveproxy`. `https://10.40.20.100:8006` antwortet aus VLAN10 **und** VLAN20 mit HTTP 200 in ~0,06 s. Wer hier einen Timeout sieht, sucht an der falschen Stelle — **und `timeout` gibt es auf macOS nicht**, ein `timeout bash -c '… /dev/tcp/…'`-Test meldet deshalb falsch-negativ.
 - ⚠️ **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.
 - 🟢 **cudy-Stand (User 2026-07-16): cudy1 (`.41.246`) auf `10.40.10.246` umgehängt** — bewusst **kein Abbau-Ziel mehr**, dient als Standalone-WLAN-Sender während der Umstellungsphase (nicht Teil des Teardowns, extern vom User selbst umkonfiguriert). **cudy2 (`.41.247`) wird nicht mehr reaktiviert** — faktisch tot, ARP-Sweep bestätigt keine Präsenz mehr auf VLAN1. B2.2 („cudy1/cudy2 stromlos/Reset/ausbauen") ist damit **erledigt/gegenstandslos** (cudy2 aus, cudy1 schon migriert statt abgebaut).
 - 🟢 **Live-Sweep 2026-07-16 (ap1, vor geplantem Teardown):** VLAN1 ist bereits viel weiter zurückgebaut als dokumentiert:

docs/tp5-deny-by-default-runbook.md

@@ -127,7 +127,14 @@ Es legt den manual Plan an, prüft `plan.device` gegen den Namen, gibt frei, dep
    `:log info ("… count=" . [:tostr [:len [… find …]]])` setzen — anschließend per `get_log` zeilengenau
    auslesen. Damit ist Root-Cause-Analyse **ohne Direkt-Write** möglich.
 
-### Etappe 1 — Log-Lauf (blockiert nichts, Dauer: einige Tage) ▸ ✅ **AUSGEROLLT 2026-08-14, läuft**
+### Etappe 1 — Log-Lauf (blockiert nichts, Dauer: einige Tage) ▸ ⏸️ **AUFGEBAUT, PAUSIERT (2026-08-14)**
+
+> ⏸️ **Pausiert, bevor gesammelt wurde** (User-Entscheid): erst die `.41.x`→`.20.x`-Altlasten aufräumen,
+> sonst besteht die abgeleitete Whitelist zu drei Vierteln aus Verkehr, den es danach nicht mehr gibt.
+> Log-Regel `disabled=yes`, Memory-Logging zurück auf `topics=info`; Kollektor und Logging-Action
+> bleiben stehen. **Wiederaufnahme = zwei Zeilen + Logdatei leeren**, s. `routeros/tp5-etappe1-pause.rsc`.
+> **Vorbedingung für die Wiederaufnahme:** Prometheus-Scrape-Ziele und die pve-Referenz `.41.100`
+> sind umgezogen bzw. entfernt (Liste in `docs/teilprojekte.md` → TP19).
 
 Ausgerollt über Nautobot GC (manual Config Plans, `nautobot/gc-manual-plan.py`), Quelle
 `routeros/tp5-etappe1-log-lauf.rsc`. Auf dem Gerät:

routeros/tp5-etappe1-pause.rsc

@@ -0,0 +1,32 @@
+# TP5 Etappe 1 — PAUSE (User-Entscheid 2026-08-14).
+# Grund: erst die .41.x -> .20.x-Migration fertigstellen (Prometheus-Scrape-Ziele,
+# HA-pve-Integration). Daten, die davor gesammelt werden, gelten danach nicht mehr —
+# 76 % des Inter-VLAN-Verkehrs waren genau dieses Altlast-Rauschen.
+#
+# Push:  python3 nautobot/gc-manual-plan.py --device crs326-core \
+#            --commands-file routeros/tp5-etappe1-pause.rsc --change-id TP5-Etappe1-Pause --deploy
+
+# 1) Log-Regel stilllegen. Bleibt als Objekt stehen (Kommentar = Idempotenz-Schluessel),
+#    das Wiederanschalten ist damit eine Zeile.
+:do { /ip firewall filter set [find comment="TP5: log-only, Vorstufe zum deny-by-default"] disabled=yes } on-error={ :log info "tp5p: disable hat geworfen" }
+
+# 2) Memory-Logging zurueckbauen. Der Ausschluss war nur wegen der Flut noetig;
+#    waehrend der Pause faellt keine an, und der On-Box-Log wird fuer die
+#    Migrationsarbeit wieder gebraucht.
+:do { /system logging set [find topics~"info" and action=memory] topics=info } on-error={ :log info "tp5p: topics-restore hat geworfen" }
+
+:log info ("tp5p: ENDE regel-disabled=" . [:tostr [/ip firewall filter get [find comment="TP5: log-only, Vorstufe zum deny-by-default"] disabled]] . " memory-topics=" . [:tostr [/system logging get [find topics~"info" and action=memory] topics]])
+
+# ===========================================================================
+# WIEDERAUFNAHME (Etappe 1 fortsetzen)
+# ===========================================================================
+# Der Kollektor laeuft weiter (Container `tp5-syslog` auf dem Docker-LXC,
+# restart=unless-stopped, 10.40.20.18:514) und die Logging-Action `tp5syslog`
+# samt Regel `topics=firewall` bleibt auf dem Core stehen — beides ist ohne die
+# Filter-Regel wirkungslos. Zum Fortsetzen genuegen zwei Zeilen:
+#
+#   /ip firewall filter set [find comment="TP5: log-only, Vorstufe zum deny-by-default"] disabled=no
+#   /system logging set [find topics~"info" and action=memory] topics=info,!firewall
+#
+# Vorher aufraeumen, sonst mischt sich Altes unter die neue Sammelphase:
+#   ssh root@10.40.20.100 'pct exec 400 -- sh -c ": > /opt/tp5-syslog/log/tp5-would-drop.log"'