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

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>

docs/tp16.3-bf-public-ap-connector-runbook.md

@@ -398,6 +398,10 @@ wie es war. Dann einfach neu absetzen.
 Das `masquerade` ist **Pflicht**, nicht Kosmetik — siehe §1.2: ohne es kommen die Pakete mit
 `172.17.0.2` am Core an, wo weder Route noch Firewall-Regel sie kennt.
 
+✅ **Seit 2026-08-31 stehen diese drei Zeilen im SOLL** (AP-Template Block `[7]`, Werte aus dem
+ConfigContext `ap-common` → `ap.container`). Wer sie hier direkt setzt, erzeugt daher **keine
+Drift mehr** — aber auch keinen Bedarf: bei einem neuen AP rendert Golden Config sie mit.
+
 ### 3.5 Image importieren und Container bauen
 
 ```bash
@@ -503,7 +507,20 @@ curl -s -X POST -H "Authorization: Bearer $CF_API_TOKEN" -H "Content-Type: appli
 ```
 Dazu **eine Ingress-Regel** für `test-tp163.emsenhuber.net` → `https://10.40.20.40:443` mit
 `originServerName: vw.emsenhuber.net` in `bf-public` ergänzen. Dann **von außerhalb des LAN, ohne
-WARP** aufrufen. Erwartet: Access-Login, **keine Redirect-Schleife**.
+WARP** aufrufen.
+
+🔑 **Das Erfolgskriterium ist praeziser, als es hier bis 2026-08-31 stand — und die frühere Fassung
+war zweideutig.** Gemessen am 2026-08-31 gegen `10.40.20.40`:
+
+| Antwort | Bedeutung |
+|---|---|
+| Access-Login, danach **`200` mit LEEREM Body** und Header **`server: Caddy`** | ✅ **Strecke bewiesen.** Caddy hat geantwortet; es gibt für `test-tp163` nur kein Site-Block, und genau so antwortet Caddy auf einen unbekannten Host. |
+| **`404`** | ❌ Die Ingress-Regel greift nicht — das ist der **Catch-all** von `bf-public` (`http_status:404`). |
+| **`ERR_TOO_MANY_REDIRECTS`** | ❌ Blocker A ist zurück (Ingress auf `:80` oder `originServerName` fehlt). Sofort abbrechen. |
+
+⚠️ **Ohne diese Tabelle liest man das leere 200 als „kaputt" und das 404 als „Caddy sagt nichts" —
+beide Male falsch herum.** Der zweite, unabhängige Beweis ist immer das Caddy-Log (§5.3).
+
 ⇒ Erst wenn das steht, wird ein Produktivname angefasst. Danach Testname + Testregel wieder entfernen.
 
 ### 5.2 Flip je Name
@@ -639,12 +656,23 @@ physischem Gang. Es schadet nicht — ohne laufenden Container ist es ein gesetz
 12. 🔴 **`docker save` liefert seit Docker 25 OCI statt docker-v1** → `no config found in manifest`.
 13. 🔴 **`/container/envs` nimmt `list=`, nicht `name=`.**
 14. 🔴 **Der `device-mode`-Bestätigungs-Boot installiert keine Pakete** — Reihenfolge s. §3.3.
-15. 🔴 **§3.4 kollidiert mit der GC-Governance:** `ip address` und `ip firewall nat` stehen unter
-    Drift-Kontrolle. Direkt gesetzt ⇒ **zwei `extra`-Drifts je AP**. Entweder vorher ins Soll heben
-    (AP-Template/ConfigContext) oder die Drift bewusst als offene Transaktion führen.
-16. 🟡 **`A - AVAILABLE` in `/system package print` ist ein Download-Katalog**, kein Paket auf dem
+15. ✅ **ERLEDIGT 2026-08-31 — §3.4 kollidierte mit der GC-Governance:** `ip address` und
+    `ip firewall nat` stehen unter Drift-Kontrolle, direkt gesetzt ergab das **zwei `extra`-Drifts
+    je AP**. Sie sind jetzt **ins Soll gehoben** (AP-Template Block `[7]` + ConfigContext
+    `ap.container`), **nicht** als Transaktion geführt: ein Dauerzustand gehört ins Template.
+    Dazu kam die **28. ComplianceRule `interface-veth`** — vorher war das veth das tragende Stück
+    **ohne jede Überwachung**. 🔴 **Falle darin:** der veth-Export trägt zwei gerätevergebene MACs;
+    ohne Normalisierung (`ConfigReplace` `60-`/`61-veth-*`) erzeugt die Regel Dauer-Drift auf allen
+    drei APs. Stand danach: **139/140**, übrig nur die offene TP25-Transaktion.
+16. 🔴 **Ein Golden-Config-Job meldet `SUCCESS` und kann trotzdem halb durchgelaufen sein.**
+    Am 2026-08-31 fehlte nach dem ersten Compliance-Lauf genau **ein** Eintrag
+    (`crs326-core`/`interface-veth`), Job-Status `SUCCESS`, im Job-Log dagegen
+    `RENDER COMPLIANCE TASK GROUP failed: Broken pipe`. **Abnahme ist deshalb nicht die
+    Konformitätsquote, sondern die ANZAHL der Einträge = Regeln × Geräte.** 139 statt 140 sieht
+    aus wie „die neue Regel greift nicht" und ist ein halb gelaufener Job. Zweiter Lauf reichte.
+17. 🟡 **`A - AVAILABLE` in `/system package print` ist ein Download-Katalog**, kein Paket auf dem
     Gerät — `enable` würde einen Internet-Fetch auslösen (auf ap1/ap2 gesperrt). `.npk` bleibt der Weg.
-17. 🟡 **MikroMCPs `export_config` exportiert unvollständig** (301 B statt 6,2 KiB). Für Backups
+18. 🟡 **MikroMCPs `export_config` exportiert unvollständig** (301 B statt 6,2 KiB). Für Backups
     `/export file=…` per SSH verwenden. Nach zwei
     Reboots je AP lohnt der Blick — die Tabelle zeigte beim CAPsMAN-Ausfall 14 h lang zufriedene
     Clients ohne Adresse.