Christoph Emsenhuber
f6283fd813
veth / ip address / ip firewall nat der drei cloudflared-Connectoren standen seit
der Vor-Ort-Session per Direkt-Write am Geraet (Runbook §3.4), waehrend /ip address
und /ip firewall unter GC-Drift-Kontrolle stehen: sechs extra-Drifts, Compliance
128/135. Sie sind inhaltlich richtig und sollen DAUERHAFT gelten -- deshalb ins
Template und nicht in eine gc-transaktion (die ist fuer befristete Versuche).
Kein Re-Baseline, kein Rueckbau, keine Zeile aufs Geraet: nur die SoT nachgezogen.
Neu ist die 28. ComplianceRule interface-veth. Vorher gab es fuer /interface veth
keine Regel -- das tragende Stueck des ganzen Aufbaus haette geloescht werden
koennen, ohne dass irgendetwas meldet.
Zwei Funde:
(a) Der veth-Export traegt zwei geraetevergebene MACs (mac-address,
container-mac-address), auf jedem AP anders. Eine nackte Regel haette damit
Dauer-Drift auf allen drei APs erzeugt, also genau die immer-rote Zahl, die
niemand mehr liest. Zwei eng auf die veth-Zeile verankerte ConfigReplace-Regeln
normalisieren sie im Backup (Lookbehind haelt container-mac-address heraus,
[^\n]*? haelt die Regel in der Zeile; Selbsttest mit Negativfaellen im Skript).
Bewusst mit der vorhandenen Maske <<REDACTED>> statt einer eigenen: sie ist im
Repo zugleich die Push-Sperre (gc-configplan.py verweigert config_set damit) --
eine Zeile mac-address=<<...>> darf nie aufs Geraet.
Kostet Backup-Treue: die veth-MACs stehen in bf-golden-config nicht mehr im
Klartext. Vertretbar, RouterOS vergibt sie beim Neuanlegen ohnehin neu.
Verworfene Alternative: MACs je Geraet modellieren -- widerspricht der
Begruendung, die fuer die VAP-MACs schon im ConfigContext-Skript steht.
(b) Der erste Compliance-Lauf meldete SUCCESS und war trotzdem unvollstaendig:
139 statt 140 Eintraege, crs326-core/interface-veth fehlte, im Job-Log
"RENDER COMPLIANCE TASK GROUP failed: Broken pipe". Zweiter Lauf sauber.
Merkregel im Runbook (Falle 16): Abnahme ist die ANZAHL der Eintraege
(Regeln x Geraete), nicht die Konformitaetsquote.
Stand danach: 139/140. Uebrig bleibt genau crs326-core/wifi-security -- die offene
Transaktion TP25-fund-e-ft-over-ds einer laufenden Messung, die bleiben muss.
Ausserdem: frischer Ingress-Snapshot von bf-public vor §5 und das geschaerfte
§5.1-Erfolgskriterium (200 mit leerem Body + server: Caddy = Strecke bewiesen,
404 = Ingress-Regel fehlt) -- am Live-System gemessen, nicht angenommen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
1 line
783 B
JSON
1 line
783 B
JSON
{"success":true,"errors":[],"messages":[],"result":{"tunnel_id":"48d3b0b6-7233-4781-a76a-1de4a5e957ce","version":3,"config":{"ingress":[{"service":"https://10.40.20.40:443","hostname":"vw.emsenhuber.net","originRequest":{"originServerName":"vw.emsenhuber.net"}},{"service":"https://10.40.20.40:443","hostname":"hass.emsenhuber.net","originRequest":{"originServerName":"hass.emsenhuber.net"}},{"service":"https://10.40.20.40:443","hostname":"n8n.emsenhuber.net","originRequest":{"originServerName":"n8n.emsenhuber.net"}},{"service":"https://10.40.20.40:443","hostname":"gitea.emsenhuber.net","originRequest":{"originServerName":"gitea.emsenhuber.net"}},{"service":"http_status:404"}],"warp-routing":{"enabled":false}},"source":"cloudflare","created_at":"2026-08-31T05:56:47.739644Z"}} |