Merge branch 'tp5-etappe1-log-lauf'
# Conflicts: # docs/teilprojekte.md
This commit is contained in:
21
routeros/tp19-core-vlan1-address-remove.rsc
Normal file
21
routeros/tp19-core-vlan1-address-remove.rsc
Normal file
@@ -0,0 +1,21 @@
|
||||
# TP19 — VLAN1-Bring-up-Adresse vom Core entfernen.
|
||||
# Ausgerollt 2026-08-15 ueber Nautobot GC (manual Config Plan), Backup davor:
|
||||
# core-pre-tp19-vlan1-addr-20260815.backup
|
||||
#
|
||||
# `10.40.41.211/24` auf `bridge` (Kommentar TP15-bringup-vlan1) war die letzte
|
||||
# .41-Spur auf dem Core und der letzte offene Compliance-Drift (ip-address).
|
||||
# Vorher geprueft: keine DNS-Statics, kein DHCP-Server auf `bridge`, kein Netwatch,
|
||||
# keine Address-Lists mit .41; `bridge` ist NICHT Mitglied der LAN-Interface-Liste.
|
||||
# Mgmt laeuft ueber .99.1 (+ Fallback 10.40.10.1), beides unberuehrt.
|
||||
#
|
||||
# ERWARTETE NEBENWIRKUNG: die dynamische Connected-Route 10.40.41.0/24 verschwindet
|
||||
# mit der Adresse. Das ist gewollt — Restverkehr nach VLAN1 scheitert danach sofort
|
||||
# statt in einen Timeout zu laufen.
|
||||
#
|
||||
# Reihenfolge war bindend und ist erfuellt: HA zeigt auf 10.40.20.100 (Integration
|
||||
# `loaded`), pve hat 10.40.41.100 nicht mehr, Prometheus/ioBroker sind umgezogen.
|
||||
#
|
||||
# Selbstprotokollierend — der Deploy-Job zeigt den Geraete-Output nicht (E1028).
|
||||
|
||||
:do { /ip address remove [find address="10.40.41.211/24"] } on-error={ :log info "tp19: remove hat geworfen" }
|
||||
:log info ("tp19: ENDE rest-41-adressen=" . [:tostr [:len [/ip address find address~"10.40.41."]]] . " rest-41-routen=" . [:tostr [:len [/ip route find dst-address~"10.40.41."]]])
|
||||
74
routeros/tp5-etappe1-log-lauf.rsc
Normal file
74
routeros/tp5-etappe1-log-lauf.rsc
Normal file
@@ -0,0 +1,74 @@
|
||||
# TP5 Etappe 1 — Log-Lauf auf crs326-core. Blockiert NICHTS.
|
||||
# Ausgerollt 2026-08-14 ueber Nautobot GC als manual Config Plans (Governance TP22),
|
||||
# nicht per Direkt-Write. Backup davor: core-pre-tp5-etappe1-20260814.backup
|
||||
#
|
||||
# Diese Datei bildet den AUSGEROLLTEN Endzustand ab. Der Weg dorthin brauchte
|
||||
# mehrere Anlaeufe; die Lehren stehen unten, damit Etappe 2-4 sie nicht wiederholen.
|
||||
# Push: python3 nautobot/gc-manual-plan.py --device crs326-core \
|
||||
# --commands-file routeros/tp5-etappe1-log-lauf.rsc --change-id TP5-Etappe1 --deploy
|
||||
|
||||
# --- 1) Syslog-Ziel ---------------------------------------------------------
|
||||
# Der Core hat nur ~3 MB freien Flash -> Disk-Logging faellt aus (Platz + Flash-Verschleiss),
|
||||
# und der Memory-Ring fasst 1000 Zeilen, den wickelt der Log-Lauf in Minuten um.
|
||||
# Kollektor: syslog-ng auf dem Docker-LXC, 10.40.20.18:514 (Container `tp5-syslog`,
|
||||
# Config /opt/tp5-syslog/config/syslog-ng.conf, Logs /opt/tp5-syslog/log/).
|
||||
# ACHTUNG Name ohne Bindestrich — s. Lehre 1.
|
||||
:do { /system logging action add name="tp5syslog" target=remote } on-error={ :log info "tp5: action add hat geworfen" }
|
||||
:do { /system logging action set [find name="tp5syslog"] remote=10.40.20.18 remote-port=514 } on-error={ :log info "tp5: action set hat geworfen" }
|
||||
|
||||
# --- 2) firewall-Topic an den Kollektor -------------------------------------
|
||||
:do { /system logging add action="tp5syslog" topics=firewall } on-error={ :log info "tp5: logging rule hat geworfen" }
|
||||
|
||||
# --- 3) firewall aus dem Memory-Ring nehmen ---------------------------------
|
||||
# Sonst besteht der 1000-Zeilen-Puffer tagelang zu 100 % aus TP5-Zeilen und der
|
||||
# On-Box-Log ist fuer jede andere Fehlersuche wertlos — genau dann, wenn man ihn braucht.
|
||||
# Matcher live geprueft: topics=info trifft NICHT (Listen-Property), topics~"info" trifft genau 1.
|
||||
# Rueckbau am Ende von Etappe 1: topics=info
|
||||
/system logging set [find topics~"info" and action=memory] topics=info,!firewall
|
||||
|
||||
# --- 4) Die Log-Regel ans ENDE der forward-Kette ----------------------------
|
||||
# action=log ist nicht-terminierend: das Paket laeuft weiter und faellt danach aus
|
||||
# der Kette in die Default-Policy (accept). Es wird nichts blockiert.
|
||||
/ip firewall filter add action=log chain=forward comment="TP5: log-only, Vorstufe zum deny-by-default" log-prefix="TP5-WOULD-DROP"
|
||||
|
||||
# --- 5) Einengung auf Nicht-WAN --------------------------------------------
|
||||
# Der erste Lauf zeigte, dass die Regel auch saemtlichen Internet-Verkehr faengt
|
||||
# (out:vlan100) — bei 242 Zeilen/min war ein Viertel davon WAN-bound, unter Last mehr.
|
||||
# LAN->WAN ist eine GARANTIERTE Whitelist-Zeile (ohne sie hat kein VLAN Internet,
|
||||
# auch die "Internet-only"-VLANs 50/90 nicht), also reines Rauschen fuer die Matrix,
|
||||
# die Etappe 2 ableiten soll.
|
||||
# 🔴 MERKPOSTEN FUER ETAPPE 3: der spaetere drop DARF NICHT bare ans Kettenende —
|
||||
# davor gehoert `accept out-interface-list=WAN`, sonst ist das ganze Haus offline.
|
||||
# Diese Zeile ist bekannt und muss nicht aus dem Log wiederentdeckt werden.
|
||||
/ip firewall filter set [find comment="TP5: log-only, Vorstufe zum deny-by-default"] out-interface-list="!WAN"
|
||||
|
||||
|
||||
# ===========================================================================
|
||||
# LEHREN AUS DEM ROLLOUT (jede am Geraet belegt, nicht vermutet)
|
||||
# ===========================================================================
|
||||
#
|
||||
# 1) 🔴 BINDESTRICHE IN `name=` WERDEN ABGELEHNT — der teuerste Fund.
|
||||
# /system logging action add name="tp5-remote" target=remote -> wirft
|
||||
# /system logging action add name="tp5-abc" target=remote -> wirft
|
||||
# /system logging action add name="tp5syslog" target=remote -> geht
|
||||
# Quoten hilft NICHT. Isoliert per :do/on-error-Plan mit Zaehler-Checkpoints.
|
||||
# Zwischenzeitlich hatte ich das faelschlich der Reihenfolge `target=`/`remote=`
|
||||
# im selben add-Statement zugeschrieben — diese Erklaerung ist WIDERLEGT
|
||||
# (`set remote=... remote-port=...` in einem Statement laeuft anstandslos).
|
||||
#
|
||||
# 2) 🔴 EIN GESCHEITERTER NETMIKO-DEPLOY HINTERLAESST EINEN TEIL-ZUSTAND.
|
||||
# Die TP22-Notiz "gescheiterter Deploy = sauberer Fehlschlag" galt dem NAPALM-Weg,
|
||||
# der scheiterte, BEVOR er das Geraet anfasste. Netmiko schickt Zeile fuer Zeile
|
||||
# und laesst Abgesetztes stehen: der erste Push hier hinterliess Zeile 3+4 auf dem
|
||||
# Geraet, ohne 1+2. **Nach jedem Fehlschlag den Geraete-Ist-Stand pruefen.**
|
||||
#
|
||||
# 3) KEINE `print`-ZEILEN IN EINEN CONFIG PLAN. Ein `/system identity print` als
|
||||
# Kanarienzeile hat die unmittelbar folgende Zeile verschluckt und eine
|
||||
# Fehldiagnose erzeugt. Config Plans enthalten nur schreibende Kommandos.
|
||||
#
|
||||
# 4) SELBSTPROTOKOLLIERENDE PLAENE SIND DIE DIAGNOSE-METHODE DER WAHL.
|
||||
# Der Deploy-Job liefert nur "E1028: found bad/failed/failure in output" und
|
||||
# zeigt den Geraete-Output NICHT. Wickelt man jedes Kommando in
|
||||
# `:do {...} on-error={ :log info "..." }` und setzt danach eine Zaehlzeile
|
||||
# `:log info ("... count=" . [:tostr [:len [... find ...]]])`, liest man das
|
||||
# Ergebnis anschliessend per get_log zeilengenau aus — ohne Direkt-Write.
|
||||
32
routeros/tp5-etappe1-pause.rsc
Normal file
32
routeros/tp5-etappe1-pause.rsc
Normal file
@@ -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"'
|
||||
26
routeros/tp5-etappe1-resume.rsc
Normal file
26
routeros/tp5-etappe1-resume.rsc
Normal file
@@ -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]])
|
||||
100
routeros/tp5-etappe2-whitelists.rsc
Normal file
100
routeros/tp5-etappe2-whitelists.rsc
Normal file
@@ -0,0 +1,100 @@
|
||||
# TP5 Etappe 2 — Whitelists auf crs326-core.
|
||||
#
|
||||
# Quelle: NICHT geraten, sondern aus 43.027 Zeilen Log-Lauf abgeleitet
|
||||
# (Kollektor 10.40.20.18, Fenster 2026-08-16T17:21 .. 2026-08-17T14:05).
|
||||
# Beobachtete Matrix (in -> out):
|
||||
# 20682 vlan20->vlan99 8082 vlan10->vlan20 7123 vlan20->vlan10
|
||||
# 6238 vlan20->vlan30 306 vlan30->vlan20 237 vlan10->vlan30
|
||||
# 214 vlan10->vlan99 17 vlan10->vlan10 2 vlan30->vlan10
|
||||
# 137 cf-mesh->{vlan20,vlan99}
|
||||
# vlan40/50/90: NULL Inter-VLAN -> Internet-only ist risikofrei (D6).
|
||||
#
|
||||
# Entscheidungen (User 2026-08-17):
|
||||
# D1 = MAIN->INFRA pauschal accept (MAIN ist das Trusted-VLAN, INFRA die
|
||||
# eigene Serverzone; Least-Privilege bleibt bei IOT/UNTRUSTED/GUEST/MGMT).
|
||||
# D4 = MGMT named sources: HA:8728 + Nautobot:22 + vlan10 + cf-mesh, Rest drop.
|
||||
# D5 = IOT->INFRA: beobachtet ist nur 8123; MQTT 1883/8883 als dokumentierte
|
||||
# Absicht mit aufgenommen (Shelly-Push kann jederzeit dazukommen).
|
||||
#
|
||||
# BLOCKIERT NICHTS: ausschliesslich action=accept. Der Drop kommt in Etappe 3.
|
||||
#
|
||||
# Push: python3 nautobot/gc-manual-plan.py --device crs326-core \
|
||||
# --commands-file routeros/tp5-etappe2-whitelists.rsc \
|
||||
# --change-id TP5-Etappe2-Whitelists --deploy
|
||||
# Backup davor: core-pre-tp5-etappe2-20260817.backup
|
||||
#
|
||||
# ABNAHMEKRITERIUM: der Zaehler der Log-Regel muss danach (nahezu) stehen
|
||||
# bleiben. Solange sie Nutzverkehr sieht, ist die Whitelist unvollstaendig —
|
||||
# das ist das Gate fuer Etappe 3.
|
||||
#
|
||||
# ---------------------------------------------------------------------------
|
||||
# WICHTIG — place-before: alle Zeilen muessen VOR die Log-Regel. Sonst laeuft
|
||||
# die Log-Regel weiter voll und das Abnahmekriterium oben ist nicht messbar
|
||||
# (action=log ist nicht-terminierend, funktional waere es egal - messbar nicht).
|
||||
# Alle Adds sind per :if [:len [find comment=...]]=0 idempotent, ein zweiter
|
||||
# Lauf legt also nichts doppelt an. Jede Zeile eigenes on-error (Lehre aus
|
||||
# Etappe 1: ein gescheiterter Netmiko-Deploy hinterlaesst Teil-Zustand).
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
# 1) LAN -> WAN. Ohne diese Zeile nimmt der spaetere Drop das ganze Haus vom
|
||||
# Netz, inklusive der "Internet-only"-VLANs 50/90. Bekannt, braucht keinen
|
||||
# Logbeleg, und aus demselben Grund stand schon die Log-Regel auf "!WAN".
|
||||
:do { :if ([:len [/ip firewall filter find comment="TP5-E2: LAN->WAN"]] = 0) do={ /ip firewall filter add chain=forward action=accept out-interface-list=WAN comment="TP5-E2: LAN->WAN" place-before=[/ip firewall filter find comment="TP5: log-only, Vorstufe zum deny-by-default"] } } on-error={ :log info "tp5e2: 01 LAN->WAN warf" }
|
||||
|
||||
# 2) Cloudflare Mesh (TP16.1/TP16.3). 137 Logtreffer belegen den Pfad.
|
||||
# Ohne diese beiden Zeilen sperrt der Drop den kompletten Fernzugang aus —
|
||||
# und zwar genau den, mit dem man den Fehler zuruecknehmen wollte.
|
||||
:do { :if ([:len [/ip firewall filter find comment="TP5-E2: mesh->LAN"]] = 0) do={ /ip firewall filter add chain=forward action=accept in-interface=cf-mesh comment="TP5-E2: mesh->LAN" place-before=[/ip firewall filter find comment="TP5: log-only, Vorstufe zum deny-by-default"] } } on-error={ :log info "tp5e2: 02 mesh->LAN warf" }
|
||||
:do { :if ([:len [/ip firewall filter find comment="TP5-E2: LAN->mesh"]] = 0) do={ /ip firewall filter add chain=forward action=accept out-interface=cf-mesh comment="TP5-E2: LAN->mesh" place-before=[/ip firewall filter find comment="TP5: log-only, Vorstufe zum deny-by-default"] } } on-error={ :log info "tp5e2: 03 LAN->mesh warf" }
|
||||
|
||||
# 3) D1 — MAIN <-> INFRA pauschal. Beobachtet waren 13 Dienste (macmini
|
||||
# udp/3722 Continuity 6234x, NAS 6690 1578x, Nautobot 8080, AirPlay 7000,
|
||||
# pve-mcp 3000, ssh auf pve/NAS/macmini, Ollama 11434, ...). Die
|
||||
# Rueckrichtung braucht eine eigene Zeile, weil Continuity je Richtung
|
||||
# eigene Flows oeffnet (7123 "new" aus vlan20).
|
||||
:do { :if ([:len [/ip firewall filter find comment="TP5-E2: MAIN->INFRA"]] = 0) do={ /ip firewall filter add chain=forward action=accept in-interface=vlan10 out-interface=vlan20 comment="TP5-E2: MAIN->INFRA" place-before=[/ip firewall filter find comment="TP5: log-only, Vorstufe zum deny-by-default"] } } on-error={ :log info "tp5e2: 04 MAIN->INFRA warf" }
|
||||
:do { :if ([:len [/ip firewall filter find comment="TP5-E2: INFRA->MAIN"]] = 0) do={ /ip firewall filter add chain=forward action=accept in-interface=vlan20 out-interface=vlan10 comment="TP5-E2: INFRA->MAIN" place-before=[/ip firewall filter find comment="TP5: log-only, Vorstufe zum deny-by-default"] } } on-error={ :log info "tp5e2: 05 INFRA->MAIN warf" }
|
||||
|
||||
# 4) INFRA -> IOT. HA (10.40.20.105) pollt ~22 Shellys auf tcp/80, 6238 Zeilen.
|
||||
# Richtungsasymmetrisch gewollt: INFRA darf IOT anfassen, nicht umgekehrt.
|
||||
:do { :if ([:len [/ip firewall filter find comment="TP5-E2: INFRA->IOT"]] = 0) do={ /ip firewall filter add chain=forward action=accept in-interface=vlan20 out-interface=vlan30 comment="TP5-E2: INFRA->IOT" place-before=[/ip firewall filter find comment="TP5: log-only, Vorstufe zum deny-by-default"] } } on-error={ :log info "tp5e2: 06 INFRA->IOT warf" }
|
||||
|
||||
# 5) D5 — IOT -> INFRA, nur Dienste. Beobachtet: 10.40.30.249 -> HA:8123 (203x).
|
||||
# MQTT mit drin, weil die Doku es als Absicht nennt und ein Shelly-Push
|
||||
# jederzeit dazukommen kann. Influx 8086 NICHT: nie beobachtet, und der
|
||||
# Weg dorthin laeuft ueber HA.
|
||||
:do { :if ([:len [/ip firewall filter find comment="TP5-E2: IOT->INFRA Dienste"]] = 0) do={ /ip firewall filter add chain=forward action=accept in-interface=vlan30 out-interface=vlan20 protocol=tcp dst-port=8123,1883,8883 comment="TP5-E2: IOT->INFRA Dienste" place-before=[/ip firewall filter find comment="TP5: log-only, Vorstufe zum deny-by-default"] } } on-error={ :log info "tp5e2: 07 IOT->INFRA warf" }
|
||||
|
||||
# 6) D4 — MGMT (vlan99). Drei named sources, sonst nichts:
|
||||
# a) MAIN komplett = Arbeitsplatz (.10.82 -> ssh/80/443 auf branch/ap1/ap2)
|
||||
# b) HA .20.105:8728 = mikrotik-Integration, 20.667 Polls. Ohne diese Zeile
|
||||
# brechen die HA-Integrationen.
|
||||
# c) Nautobot .20.30:22 = Netmiko-Deploy der Golden Config. Ohne diese Zeile
|
||||
# sperrt sich TP22 selbst aus — der Weg, ueber den dieser Push laeuft.
|
||||
# cf-mesh ist bereits durch Zeile 2 gedeckt.
|
||||
:do { :if ([:len [/ip firewall filter find comment="TP5-E2: MAIN->MGMT"]] = 0) do={ /ip firewall filter add chain=forward action=accept in-interface=vlan10 out-interface=vlan99 comment="TP5-E2: MAIN->MGMT" place-before=[/ip firewall filter find comment="TP5: log-only, Vorstufe zum deny-by-default"] } } on-error={ :log info "tp5e2: 08 MAIN->MGMT warf" }
|
||||
:do { :if ([:len [/ip firewall filter find comment="TP5-E2: HA->MGMT api"]] = 0) do={ /ip firewall filter add chain=forward action=accept src-address=10.40.20.105 out-interface=vlan99 protocol=tcp dst-port=8728 comment="TP5-E2: HA->MGMT api" place-before=[/ip firewall filter find comment="TP5: log-only, Vorstufe zum deny-by-default"] } } on-error={ :log info "tp5e2: 09 HA->MGMT warf" }
|
||||
:do { :if ([:len [/ip firewall filter find comment="TP5-E2: Nautobot->MGMT ssh"]] = 0) do={ /ip firewall filter add chain=forward action=accept src-address=10.40.20.30 out-interface=vlan99 protocol=tcp dst-port=22 comment="TP5-E2: Nautobot->MGMT ssh" place-before=[/ip firewall filter find comment="TP5: log-only, Vorstufe zum deny-by-default"] } } on-error={ :log info "tp5e2: 10 Nautobot->MGMT warf" }
|
||||
|
||||
# 7) Same-VLAN mDNS. vlan10 -> vlan10 udp/5353, erzeugt vom mDNS-Repeater auf
|
||||
# dem Core selbst (17 Zeilen). Erreicht die forward-Kette und wuerde von
|
||||
# einem blanken Drop getroffen -> Discovery INNERHALB von MAIN kaputt.
|
||||
:do { :if ([:len [/ip firewall filter find comment="TP5-E2: same-VLAN mDNS"]] = 0) do={ /ip firewall filter add chain=forward action=accept in-interface=vlan10 out-interface=vlan10 protocol=udp dst-port=5353 comment="TP5-E2: same-VLAN mDNS" place-before=[/ip firewall filter find comment="TP5: log-only, Vorstufe zum deny-by-default"] } } on-error={ :log info "tp5e2: 11 same-VLAN mDNS warf" }
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# BEWUSST NICHT AUFGENOMMEN:
|
||||
#
|
||||
# vlan10 -> vlan30 (237x udp/3722) und vlan30 -> vlan10 (2x): das ist das
|
||||
# iPhone 10.40.30.201, das im IOT-SSID haengt. D2 ist entschieden — es wird
|
||||
# ins MAIN-SSID umgehaengt (Hands-on bei Christoph), dann verschwindet die
|
||||
# Richtung von selbst. Eine Whitelist auf .30.201 waere ausserdem instabil:
|
||||
# iOS vergibt pro SSID eine eigene Private Address.
|
||||
# => Vor Etappe 3 pruefen, ob die Zeilen aus dem Log verschwunden sind.
|
||||
#
|
||||
# MAIN -> IOT ICMP (lanscan.app, D3): keine Dauerregel. Gehoert in die
|
||||
# JIT-Admin-Gruppe (address-list mit timeout), Etappe 4.
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
# Zaehlzeile: 11 Whitelist-Regeln erwartet. Per get_log zeilengenau auslesen —
|
||||
# der Deploy-Job zeigt den Geraete-Output nicht (Lehre aus Etappe 1).
|
||||
:log info ("tp5e2: ENDE whitelist-regeln=" . [:tostr [:len [/ip firewall filter find comment~"TP5-E2:"]]] . " logregel-disabled=" . [:tostr [/ip firewall filter get [find comment="TP5: log-only, Vorstufe zum deny-by-default"] disabled]])
|
||||
Reference in New Issue
Block a user