admin/bf-infra
1
0
Fork 0
Code Issues 21 Pull Requests Actions Packages Projects Releases Wiki Activity

TP16.3 §5: die sechs AP-Drifts ins Soll, 28. Regel interface-veth

Browse Source 
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>
This commit is contained in:
Christoph Emsenhuber
2026-08-31 20:13:47 +02:00
parent 4cd091379e
commit f6283fd813
6 changed files with 359 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files

28
nautobot/mikrotik_routeros.j2
View File

@@ -535,4 +535,32 @@
/interface vlan add interface={{ ap.bridge }} name=vlan{{ ap.mgmt.vlan }} vlan-id={{ ap.mgmt.vlan }}
/ip address add address={{ obj.primary_ip4.address }} interface=vlan{{ ap.mgmt.vlan }} network={{ mgmt_host.split(".")[:3] | join(".") }}.0
/ip route add comment="mgmt default via core" dst-address=0.0.0.0/0 gateway={{ ap.mgmt.gateway }}
{% if ap.container %}
# [7] CONTAINER-NETZ des cloudflared-Connectors (TP16.3 §5, ins Soll gehoben 2026-08-31)
# Bis hierher standen diese Zeilen per DIREKT-WRITE am Geraet (Runbook §3.4) und
# erzeugten je AP zwei extra-Drifts: Runbook und GC-Governance widersprachen sich,
# /ip address und /ip firewall stehen unter Drift-Kontrolle. Sie gehoeren ins Soll
# und NICHT in eine gc-transaktion: eine Transaktion ist ein befristeter Versuch,
# das hier ein Dauerzustand.
#
# 🔴 Das masquerade ist Pflicht, nicht Kosmetik. Der Container spricht aus 172.17.0.2;
# dem Core ist 172.17.0.0/24 unbekannt, es gibt weder Route noch Rueckweg. Erst
# hinter dem masquerade kommt der Verkehr als vlan99 an und wird von der Freigabe
# "TP31: AP-cloudflared -> caddy-bf1" (vlan99 -> vlan20:443) getragen.
#
# 🔑 <<REDACTED>> steht hier NICHT fuer ein Geheimnis, sondern fuer zwei
# geraetevergebene MACs, die auf jedem AP anders lauten und in Nautobot bewusst
# nicht modelliert sind (gleiche Entscheidung wie bei den VAP-MACs, s. [1]).
# Die ConfigReplace-Regeln 60-/61-veth-* normalisieren sie im Backup
# (nautobot/ingest-veth-rule.py). Zweiter, willkommener Effekt: die Maske ist die
# Push-Sperre aus TP22-Regel 1 -- eine Zeile mac-address=<<...>> darf nie aufs Geraet.
#
# Ein kuenftiger AP ohne Connector setzt "container": {} per local_config_context_data;
# dann rendert dieser Block nichts und die Regel interface-veth vergleicht leer gegen leer.
{% set c = ap.container %}
/interface veth add address={{ c.veth_address }} container-mac-address=<<REDACTED>> dhcp=no gateway={{ c.gateway }} gateway6="" mac-address=<<REDACTED>> name={{ c.veth }}
/ip address add address={{ c.ap_address }} interface={{ c.veth }} network={{ c.network }}
/ip firewall nat add action=masquerade chain=srcnat comment="{{ c.nat_comment }}" src-address={{ c.subnet }}
{% endif %}
{% endif %}