TP5 Etappe 1: Sammelphase laeuft, VLAN1-Rueckbau abgenommen

Abnahme bestanden: out:bridge = 0 ueber ein 10-Minuten-Fenster (Logdatei
vorher geleert). Vorher waren vlan20 -> bridge 76 % des gesamten
Inter-VLAN-Verkehrs; die Rate fiel von ~166 auf ~34 Zeilen/min.

Beobachtete Matrix (339 Zeilen / 10 min) als Arbeitsmaterial fuer Etappe 2
festgehalten. Zwei Befunde daraus:

- D4 ist belegt statt geschaetzt: der Management-Pfad ist HA (10.40.20.105),
  das ueber seine mikrotik-Integrationen 8728 auf branch/ap1 pollt (je 67x).
  Ohne Whitelist sperrt der spaetere Drop die Netzverwaltung aus.
- Neuer Merkposten: same-VLAN-Verkehr erreicht die forward-Kette —
  vlan10 -> vlan10 unicast mDNS, erzeugt vom mDNS-Repeater auf dem Core.
  Harmlos, aber ein blanker Drop wuerde Discovery innerhalb von MAIN
  beschaedigen.

Damit sind drei Whitelist-Zeilen bekannt, bevor Etappe 2 beginnt:
LAN->WAN, der Mgmt-Pfad, und same-VLAN-mDNS.

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

docs/teilprojekte.md

@@ -205,8 +205,21 @@ 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 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`.
+### TP5 — Firewall & Inter-VLAN-Policy ▸ 🟢 **ETAPPE 1: SAMMELPHASE LÄUFT** (seit 2026-08-16) — 📋 `docs/tp5-deny-by-default-runbook.md`
+- ✅ **ABNAHME DES VLAN1-RÜCKBAUS BESTANDEN (2026-08-16): `out:bridge` = 0.** 10-Minuten-Messfenster nach dem Wiederanschalten, Logdatei vorher geleert. Vorher waren `vlan20 → bridge` **76 %** des gesamten Inter-VLAN-Verkehrs. Die Rate fiel von ~166 auf ~34 Zeilen/min — der Rückbau hat das Log auf echten Nutzverkehr eingedampft. Wiederaufnahme über `routeros/tp5-etappe1-resume.rsc` (GC, Backup `core-pre-tp5-resume-20260815.backup`).
+- 📊 **Beobachtete Matrix, 339 Zeilen / 10 min** — das Arbeitsmaterial für Etappe 2:
+
+  | Paar | Zeilen | was genau |
+  |---|---|---|
+  | `vlan20 → vlan99` | 126 | **HA `10.40.20.105` → `10.40.99.2:8728` + `10.40.99.11:8728`** (je 67) = der Management-Pfad |
+  | `vlan20 → vlan30` | 85 | HA → IoT: `.30.211:80` (44), `.30.8:10081` (22), `.30.244:8080` Nuki (22), `.30.5:631` Drucker (4) |
+  | `vlan10 → vlan20` | 65 | Arbeitsplatz → INFRA |
+  | `vlan20 → vlan10` | 61 | INFRA → MAIN |
+  | `vlan10 → vlan10` | 2 | **mDNS `10.40.10.183:5353 → 10.40.10.82:5353`** — s.u. |
+
+- 🔑 **D4 ist damit belegt, nicht mehr geschätzt:** der Management-Pfad ist **HA** (`10.40.20.105`), das über seine vier `mikrotik`-Integrationen `8728` auf branch/ap1/ap2 pollt (core `.99.1` erscheint nicht, weil das `input` ist, nicht `forward`). Dazu MikroMCP vom Arbeitsplatz. **Ohne Whitelist sperrt der spätere Drop die Verwaltung des eigenen Netzes aus.**
+- ⚠️ **Neuer Merkposten für Etappe 3 — same-VLAN-Verkehr erreicht die `forward`-Kette:** `vlan10 → vlan10`, unicast **mDNS** zwischen zwei MAIN-Clients, erzeugt vom mDNS-Repeater auf dem Core. Zwei Pakete in 10 Minuten, harmlos — **aber ein blanker Drop am Kettenende würde sie treffen** und damit Discovery *innerhalb* von MAIN beschädigen. Zusammen mit `accept out-interface-list=WAN` die zweite Regel, die bekannt ist und nicht aus dem Log wiederentdeckt werden muss.
+- ✅ **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`).

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

@@ -127,14 +127,21 @@ 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) ▸ ⏸️ **AUFGEBAUT, PAUSIERT (2026-08-14)**
+### Etappe 1 — Log-Lauf (blockiert nichts, Dauer: einige Tage) ▸ 🟢 **SAMMELPHASE LÄUFT (seit 2026-08-16)**
 
-> ⏸️ **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).
+> Historie: am 2026-08-14 **vor** der Sammelphase pausiert, weil 76 % des Verkehrs `.41.x`-Altlast war.
+> Nach dem VLAN1-Rückbau (TP19) am 2026-08-16 wieder scharf — `routeros/tp5-etappe1-resume.rsc`.
+>
+> ✅ **Abnahme bestanden: `out:bridge` = 0** über ein 10-Minuten-Fenster (Logdatei vorher geleert).
+> Rate von ~166 auf ~34 Zeilen/min gefallen. Die beobachtete Matrix steht in
+> `docs/teilprojekte.md` → TP5 und ist ab jetzt das Arbeitsmaterial für Etappe 2.
+>
+> **Zwei Regeln stehen damit schon fest und brauchen keinen weiteren Beleg aus dem Log:**
+> 1. `accept out-interface-list=WAN` — ohne sie nimmt der Drop das ganze Haus vom Netz.
+> 2. Der **Management-Pfad** `10.40.20.105 → 10.40.99.{2,11,12}:8728` (HA-`mikrotik`-Integrationen)
+>    plus MikroMCP vom Arbeitsplatz — sonst sperrt der Drop die Netzverwaltung aus.
+> 3. **Same-VLAN-mDNS** (`vlan10 → vlan10`, `5353`, vom Repeater auf dem Core erzeugt) erreicht die
+>    `forward`-Kette und würde von einem blanken Drop getroffen.
 
 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-resume.rsc

@@ -0,0 +1,26 @@
+# TP5 Etappe 1 — WIEDERAUFNAHME nach der Pause vom 2026-08-14.
+# Gegenstueck zu routeros/tp5-etappe1-pause.rsc.
+#
+# Der Grund fuer die Pause ist weg: die .41.x-Altlasten sind abgeraeumt
+# (HA -> 10.40.20.100, pve .41.100 entfernt, Core .41.211 entfernt,
+# Prometheus bereinigt, ioBroker korrigiert). Vorher waren 76 % des
+# Inter-VLAN-Verkehrs `vlan20 -> bridge`, also genau dieses Rauschen.
+#
+# Push:  python3 nautobot/gc-manual-plan.py --device crs326-core \
+#            --commands-file routeros/tp5-etappe1-resume.rsc \
+#            --change-id TP5-Etappe1-Resume --deploy
+# Backup davor: core-pre-tp5-resume-20260815.backup
+#
+# ABNAHME danach: `out:bridge` im Kollektor-Log muss auf 0 stehen.
+# Die Logdatei ist vor dem Scharfschalten geleert worden.
+
+# 1) Log-Regel wieder scharf. Blockiert nichts: action=log ist nicht-terminierend,
+#    und out-interface-list="!WAN" haelt den Internet-Verkehr draussen.
+:do { /ip firewall filter set [find comment="TP5: log-only, Vorstufe zum deny-by-default"] disabled=no } on-error={ :log info "tp5r: enable hat geworfen" }
+
+# 2) firewall wieder aus dem Memory-Ring nehmen. Sonst besteht der 1000-Zeilen-Puffer
+#    waehrend der Sammelphase zu 100 % aus TP5-Zeilen und der On-Box-Log ist fuer
+#    jede andere Fehlersuche wertlos — genau dann, wenn man ihn braucht.
+:do { /system logging set [find topics~"info" and action=memory] topics=info,!firewall } on-error={ :log info "tp5r: topics hat geworfen" }
+
+:log info ("tp5r: ENDE 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]])