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>
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>
Log-only-Regel am Ende der forward-Kette (blockiert nichts) plus Syslog-
Kollektor, ausgerollt ueber Nautobot GC als manual Config Plans.
- routeros/tp5-etappe1-log-lauf.rsc: der ausgerollte Endzustand + die am
Geraet belegten Lehren aus dem Rollout
- nautobot/gc-manual-plan.py: Push-Werkzeug (assertet plan.device, liest
Plan-Status statt Job-Status, strippt Kommentarzeilen)
Zwei Korrekturen an bisherigen Annahmen:
- Ein gescheiterter Netmiko-Deploy hinterlaesst einen TEIL-Zustand. Die
TP22-Notiz "sauberer Fehlschlag" galt dem NAPALM-Weg.
- Bindestriche in name= werden von RouterOS abgelehnt, Quoten hilft nicht.
Die zuerst notierte target=/remote=-Erklaerung war falsch und ist raus.
Die Log-Regel steht auf out-interface-list="!WAN": bare fing sie auch allen
Internet-Verkehr. LAN->WAN ist eine garantierte Whitelist-Zeile, also
Rauschen - und ein Merkposten fuer Etappe 3, wo der Drop aus demselben
Grund nicht bare stehen darf.
D2 entschieden: iPhone .30.201 wird ins MAIN-SSID umgehaengt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der Dauersweep von .10.82 auf alle Shellys ist lanscan.app — ein Ad-hoc-Scan vom
Arbeitsplatz, kein Dienst. Also keine permanente MAIN->IOT-ICMP-Regel, sondern
Teil der selbstverfallenden JIT-Admin-Gruppe (deckt sich mit D4).
Hinweis fuer den Log-Lauf ergaenzt: der Scan erzeugt sonst Rauschen in Etappe 1.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
TP5 (Deny-by-default) ist nach TP22 der kritische Pfad und jetzt einsatzbereit
vorbereitet — auf Live-Erhebung von crs326-core statt aus der Doku.
Neu:
- docs/tp5-deny-by-default-runbook.md: Ist-Stand forward/input/NAT/Interface-
Listen, Inter-VLAN-Flow-Matrix aus conntrack + Countern, offene Entscheidungen
D1–D6, 4 Etappen (Etappe 1 = reiner Log-Lauf ohne Blockierung), Rollback.
- docs/doku-cleanup-session.md: Arbeitsliste A–E für die Aufräum-Session
(Ist-Stand-Block, Reihenfolge-Liste, stale "ap1 = Router"/CAPsMAN-Aussagen).
Statuskorrekturen in teilprojekte.md:
- TP21.1 Punkt 4: TV-End-to-End-Beweis erbracht (Ping 5/5, MAC auf ether4/VID40
gelernt, RX 1.338 -> 6.909 Pakete). Das Kabel-Follow-up entfaellt — geloest
wurde am Port, nicht am Kabel.
- TP19.1: WIP -> erledigt (ap2 seit TP3-Rebuild auf .99.12, sw1/sw2 ausgebaut
und in Nautobot Decommissioned).
- TP5: Holes + WAN-Seal auf crs326-core re-verifiziert — die Verifikation vom
2026-07-02 galt ap1, das seit 2026-08-08 Werksreset ist. Befund: die 5
mDNS-Input-Regeln sind hinter TP10-seal-lan wirkungslos (0 Pakete).
- Ist-Stand-Block als Historie markiert, "Naechster Schritt" auf TP5 -> TP6.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
