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

19
nautobot/ingest-ap-configcontext.py
View File

@@ -58,6 +58,25 @@ AP_COMMON = {
# local_config_context_data. (Nautobot merged Dicts tief, LISTEN ERSETZEND —
# genau das ist hier gewollt.)
"extra_ports": ["ether3", "ether4", "ether5"],
# Container-Netz des cloudflared-Connectors (TP16.3 §5, 2026-08-31). Bis dahin
# standen veth / ip address / nat per Direkt-Write am Geraet und erzeugten zwei
# extra-Drifts JE AP -- Runbook §3.4 und die GC-Governance widersprachen sich.
# Sie sind hier ins Soll gehoben, weil sie DAUERHAFT gelten sollen: ein
# Dauerzustand gehoert ins Template, nicht in eine gc-transaktion mit Ablaufdatum.
# 🔴 Das masquerade ist Pflicht, nicht Kosmetik: ohne es kommen die Pakete mit
# 172.17.0.2 am Core an, wo weder Route noch Firewall-Regel sie kennt -- die
# Freigabe vlan99->vlan20:443 aus Blocker B traegt sie dann nicht.
# Jeder Wert hier ist EIN Token der Export-Zeile, bewusst ausgeschrieben statt
# gerechnet: ein falscher join() faellt nicht auf, er wird zu Dauer-Drift.
"container": {
"veth": "veth-cf",
"veth_address": "172.17.0.2/24", # Container-Seite -> /interface veth
"gateway": "172.17.0.1", # AP-Seite ohne Prefix -> /interface veth
"ap_address": "172.17.0.1/24", # AP-Seite -> /ip address
"network": "172.17.0.0", # -> /ip address network=
"subnet": "172.17.0.0/24", # -> nat src-address=
"nat_comment": "TP31: cloudflared egress",
},
"mgmt": {"vlan": 99, "gateway": "10.40.99.1"},
"native_vlan": 1,
# Liste (nicht Dict): Reihenfolge ist garantiert und diffbar.