75 lines
5.0 KiB
Plaintext
75 lines
5.0 KiB
Plaintext
# 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.
|