TP16.1 Nachlauf: Mgmt-ACL via GC auf alle 4 Geraete (72/72), CF-Schalter entschieden

Neue Compliance-Feature ip-service (17->18 Regeln, 68->72 Checks). Sollzustand
einheitlich im Template: ssh/www/winbox/api = 10.40.0.0/16,100.96.0.0/12;
ftp/telnet/api-ssl disabled. Deploy gestaffelt (ap2 zuerst, am Geraet
gegengeprueft), Job liegt als 'mgmt-acl' in gc-configplan.py.

Befund war invertiert: branch/ap1/ap2 hatten GAR KEINE Address-Beschraenkung
und waren laengst per Mesh erreichbar; winbox war auf allen vier offen. Aus dem
Erreichbarkeits-Fix wurde eine Haertung. ftp/telnet/api-ssl dabei abgeschaltet.

CF-Schalter 'Allow all Cloudflare One traffic to reach enrolled devices':
recherchiert, bleibt AUS - er oeffnet die Client<->Client-Richtung, unsere laeuft
ohne ihn. Kein API-Feld, CF-Docs widersprechen sich (Profil- vs. globale
Einstellung).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/tp16.1-warp-mesh-native-crs326.md

@@ -13,10 +13,10 @@
 > 3. **MikroMCP taugt für WireGuard nur halb** (§4.3): kein Privkey möglich, und `endpoint="IP:Port"` wird
 >    falsch zerlegt → kein Handshake.
 >
-> 🔴 **Einziger verbliebener Punkt, user-gated:** der Dashboard-only-Schalter „Allow all Cloudflare One traffic
-> to reach enrolled devices" (§4.1 Schritt 2). **Der Mesh läuft nachweislich auch ohne ihn** — CF führt ihn als
-> Prerequisite, für Device→Node/Subnetz war er offenkundig nicht nötig. Vermutlich zählt er erst für
-> **Client↔Client** (Gerät zu Gerät). Setzen, wenn das gebraucht wird. `POST /warp_connector` erfolgreich:
+> ✅ **Nachlauf am selben Tag, ebenfalls abgeschlossen:** die **Mgmt-ACL wurde via Golden Config auf alle vier
+> Geräte ausgerollt** (neue Compliance-Feature `ip-service`, **72/72 compliant**) — s. §4.7. Und der
+> Dashboard-Schalter ist **recherchiert und bewusst AUS** — s. §4.1 Schritt 2. **TP16.1 hat damit keine
+> offenen Punkte mehr**, außer den weiterhin getrennt geführten Fremdthemen (TP16-HA, TP5-Firewall). `POST /warp_connector` erfolgreich:
 > **`bf-core-mesh` = `d1da7c8a-2736-4cbb-8af1-32db5393fb9c`**, Register-Token in `mcp/cloudflare/.env`
 > (`CF_MESH_REGISTER_TOKEN`, gitignored, `chmod 600`). ➡️ **Die seit 2026-07-17 offene Free-Plan-Frage ist damit
 > beantwortet: der Free-ZT-Plan erlaubt Cloudflare Mesh. Der LXC-Fallback (§6) ist vom Tisch.**
@@ -212,11 +212,23 @@ tunnel-spezifischen Doc-Seiten, die noch die alten Namen zeigen). Im Token-Edito
 | Schritt | Stand |
 |---|---|
 | 1. Unique Device IP | ✅ `use_zt_virtual_ip: true` gesetzt (PATCH `devices/settings`) |
-| 2. „Allow all Cloudflare One traffic to reach enrolled devices" | 🔴 **OFFEN — Dashboard-only, kein API-Feld** (s.u.) |
+| 2. „Allow all Cloudflare One traffic to reach enrolled devices" | ✅ **entschieden: bleibt AUS** — nicht nötig (s.u.) |
 | 3. Device-Profil „Cloudflare Mesh" | ✅ `4d3c0f57-a717-49ac-ab92-b420e33e6380`, match `identity.email == "warp_connector@emsenhuber.cloudflareaccess.com"`, `tunnel_protocol=wireguard`, precedence 100 |
 | 4. Split-Tunnel-Exclude | ✅ auf **beiden** Profilen: `100.64.0.0/10` raus, `100.64.0.0/11` + `100.112.0.0/12` rein (14→15 bzw. 16→15 Einträge) |
 | 5. ICMP-Proxy | ✅ war schon an, nichts zu tun (s. §4.1.5) |
 
+> ✅ **Schritt 2 — recherchiert 2026-08-17, Entscheid: bleibt AUS.** Die CF-**Settings-Referenz** führt ihn unter
+> „Global device client settings" (also **global**, nicht per Profil — die Mesh-Get-Started-Seite behauptet das
+> Gegenteil, **die Docs widersprechen sich**). Verfügbar in **allen Plänen**, alle OS, Client-Mode „Traffic and
+> DNS". **Was er tut:** er lässt Traffic aus Mesh/WAN **zu den eingebuchten Geräten hin** — Zugriff auf
+> *Device-IPs*, also die **Client↔Client**-Richtung. **Unser Anwendungsfall ist die andere Richtung**
+> (Gerät → Mesh-Node → `10.40.0.0/16`), und der funktioniert bewiesenermaßen ohne ihn (§4.5). Die CF-Docs
+> nennen **keinen** Menüpfad, und es gibt **kein API-Feld** (Spec, `devices/settings`-PATCH und Profil-GET
+> gegengeprüft). **Nach User-Vorgabe „im Zweifel ohne Schalter" nicht gesetzt.** Erst dann relevant, wenn
+> Zugriff **auf ein Endgerät** statt auf das Netz gebraucht wird.
+
+<details><summary>Ursprüngliche Handlungsanweisung (vor der Recherche)</summary>
+
 > 🔴 **Schritt 2 ist der einzige verbliebene Handgriff und NUR im Dashboard machbar.** Weder
 > `PATCH /devices/settings` noch `POST /devices/policy` kennen ein entsprechendes Feld — im OpenAPI-Spec **und** in
 > der GET-Antwort des Default-Profils taucht es nicht auf (gegengeprüft 2026-08-17). Es verhält sich damit genau
@@ -225,6 +237,43 @@ tunnel-spezifischen Doc-Seiten, die noch die alten Namen zeigen). Im Token-Edito
 > to reach enrolled devices"** einschalten. ⚠️ Laut CF-Doc ist das eine **Profil**-Einstellung — unser Runbook
 > führte sie fälschlich als Account-Einstellung („gleiche Seite" wie Unique Device IP).
 
+</details>
+
+### 4.7 Mgmt-ACL via Golden Config auf alle vier Geräte — ✅ **ERLEDIGT 2026-08-17, `72/72 compliant`**
+
+Der `/ip service`-Fix aus §4.5 war zunächst nur am Core und **direkt** gesetzt. Nachgezogen als sauberer
+GC-Rollout auf **alle vier** Geräte.
+
+**Der Befund war das Gegenteil der Erwartung.** §4.5 schloss mit „für `branch`/`ap1`/`ap2` noch offen — die
+haben eigene `/ip service`-Beschränkungen". **Falsch:** sie hatten **gar keine** — `ssh`, `www`, `winbox`,
+`api`, `ftp`, `telnet` alle aktiv und **ohne** Address-Beschränkung. Die dynamischen Einträge zeigten sogar
+`REMOTE 100.96.0.1`, waren also längst per Mesh erreichbar. Und **`winbox` war auf allen vier offen**, auch am
+Core. Damit wurde aus dem erwarteten Erreichbarkeits-Fix eine **Härtung**.
+
+| | Sollzustand (einheitlich, im Template) |
+|---|---|
+| `ssh` · `www` · `winbox` · `api` | `address=10.40.0.0/16,100.96.0.0/12` |
+| `ftp` · `telnet` · `api-ssl` | `disabled=yes` |
+
+- **Neue Compliance-Feature `ip-service`** (`match_config=/ip service`, `config_type=cli`,
+  `config_ordered=false`) → 17→18 Regeln, **68→72 Checks**. Ohne die Regel stünde die ACL zwar im Template,
+  würde aber **nie verglichen** — der Rollout wäre nicht durchsetzbar.
+- **Ablauf regelkonform:** `/system backup` auf allen Zielen → `--job mgmt-acl` (Dry-Run) →
+  `--apply --no-deploy` → **gestaffelter** Deploy: erst `ap2`, am Gerät gegengeprüft, dann `ap1`/`branch`/`core`
+  → Geräte-Gegenprobe → `--refresh-compliance`.
+- **Kein Lockout-Risiko:** der Deploy läuft von Nautobot (`10.40.20.30`) aus, also aus `10.40.0.0/16` — in jeder
+  gesetzten ACL enthalten. RouterOS wendet `address=` ohnehin erst auf **neue** Verbindungen an.
+- ⚠️ **Scope-Erweiterung, bewusst:** `ftp`/`telnet`/`api-ssl` auf branch/ap1/ap2 **abgeschaltet**. Die
+  Alternative wäre gewesen, „telnet aktiv" als **Sollzustand** in die SoT zu schreiben. Nichts hier nutzt sie
+  (der ALLNET-Telnet-Runner ist Archiv, das Gerät ausgebaut).
+- 📌 **Schreibweise:** `/ip service set ssh …` mit dem **Dienstnamen**, NICHT `[find name=ssh]` — letzteres
+  trifft auch den dynamischen Verbindungs-Eintrag → `failure: this is configured elsewhere`.
+- 🧪 **Mess-Falle am Rande:** `[/ip service get … address]` in einem `:put`-Ausdruck verketten erzeugt bei
+  **zwei** ACL-Einträgen das **Kreuzprodukt** (16 Zeilen statt 1) — `address` ist eine Liste. Zum Prüfen
+  `/ip service print detail` nehmen, nicht String-Verkettung.
+
+Job liegt als `mgmt-acl` in `nautobot/gc-configplan.py` (idempotent, wiederholbar).
+
 > 📎 **Nachtrag zu Schritt 3/4 aus den CF-Docs (gelesen 2026-08-17):** CF empfiehlt für Mesh-*Nodes* eigentlich ein
 > Profil im **Include**-Modus mit `100.96.0.12` — das gilt für Nodes, die den **Cloudflare One Client** fahren.
 > Unser Node ist **natives RouterOS-WireGuard** und konsumiert überhaupt kein Device-Profil; für ihn zählt