RouterBOOT-Klickanleitung + TP5 E3/E4 abgenommen, NTP-Zeitquelle, Template-Fixes

docs/routerboot-firmware-klickanleitung.md: Schritt-fuer-Schritt fuer WinBox.
RouterOS ist auf allen vier bereits 7.24, nur der Bootloader haengt zurueck
(core/branch 7.19.5, ap1/ap2 7.23.2 -- live erhoben). Der Weg geht per Hand,
weil `/system routerboard upgrade` interaktiv nachfragt: MikroMCP blockt ihn per
Deny-Policy, und Netmiko bekommt den Prompt statt einer Antwort und quittiert mit
E3001 bei LEERER Fehlermeldung. Auf core/branch waere ein Scheduler-Umweg
moeglich, auf den APs nicht (device-mode=home sperrt ihn).
Reihenfolge ap1 -> ap2 -> core -> branch mit Ausfall je Geraet; branch zuletzt,
weil der Arbeitsplatz per Kabel daran haengt. Dazu Gegenprobe-Einzeiler fuer alle
vier und die Falle, dass ohne Schritt 7 (Reboot) `Current Firmware` alt bleibt.

Aus der Parallelsession dazugekommen:
- TP5 Etappe 3 UND 4 sind abgenommen, beide Auto-Reverts abbestellt. Die
  Abnahmen stehen in den Skriptkoepfen: forward-Drop hat in der Testphase 11
  Pakete gefressen, ausschliesslich die eigene pve->branch:22-Sonde; beim
  input-Drop war es reines Broadcast-Rauschen (NetBIOS, SSDP). Der GC-Deploy-Pfad
  wurde als Pfadbeweis mitgetestet (nautobot-worker -> ap2:22 = SUCCESS).
- E4-Nachtrag: MNDP und CAPWAP muessen in den input. Die CAPs finden ihren
  Manager per Layer-2-Discovery (`current-caps-man-address` ist eine MAC, keine
  IP) -- bestehende Sitzungen laufen ueber seal-est weiter, der Bruch schluege
  also erst beim naechsten AP- oder Manager-Neustart zu.
- TP19 NTP: alle drei Nicht-Core-Geraete fragten einen Zeitserver, den es nicht
  gab (`status=waiting`, branch hatte gar keinen). ap2 war 17 Stunden nach und
  hat einen Logeintrag von 04:57 als 12:19 gestempelt -- geraeteuebergreifende
  Korrelation war damit wertlos. Core wird Zeitquelle, die drei werden Clients.
- Template: `/ip service` exportiert `available-from=`, nicht `address=`. Das
  Soll war falsch und das Geraet hatte recht -- vier Dauer-Drifts. Und
  `hw-offload` fliegt aus dem Firewall-Renderer, weil REST es meldet und
  /export es weglaesst.

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

nautobot/ingest-core-firewall.py

@@ -32,7 +32,13 @@ DEVICE = "crs326-core"
 SECRETS = pathlib.Path.home() / ".secrets" / "credentials.env"
 
 # Felder, die RouterOS im Export NICHT schreibt (Laufzeit-/Interndaten).
-SKIP = {".id", "dynamic", "invalid", "bytes", "packets", "creation-time"}
+# `hw-offload` gehoert dazu (2026-08-18 aufgeschlagen): die REST-API meldet es
+# auf der defconf-fasttrack-Regel als true, `/ip firewall filter export` laesst
+# es weg -- am Geraet gegengeprueft. Ohne diesen Eintrag meldet die Compliance
+# ewige Falsch-Drift auf genau dieser einen Regel. Gleiche Klasse wie die
+# `disabled=false`- und Boolean-Faelle weiter unten.
+SKIP = {".id", "dynamic", "invalid", "bytes", "packets", "creation-time",
+        "hw-offload"}
 
 
 def secret(key):

nautobot/mikrotik_routeros.j2

@@ -20,12 +20,16 @@
 # winbox war auf ALLEN vier unbeschraenkt.
 # ⚠️ Lockout-Regel: 10.40.0.0/16 (LAN) UND 100.96.0.0/12 (Mesh) muessen beide drin sein —
 # das sind die zwei Wege, ueber die dieses Netz administriert wird. Nie einen davon kappen.
+# ⚠️ Attribut heisst `available-from`, NICHT `address` (korrigiert 2026-08-18): RouterOS
+# 7.23/7.24 exportiert `available-from=`, das Template schrieb `address=`. Ergebnis waren
+# vier Dauer-Drifts (ap1/ap2/branch/core), bei denen das GERAET recht hatte und das Soll
+# falsch war. Beim Push haette `address=` auf 7.24 zudem auflaufen koennen.
 /ip service set ftp disabled=yes
-/ip service set ssh address=10.40.0.0/16,100.96.0.0/12
+/ip service set ssh available-from=10.40.0.0/16,100.96.0.0/12
 /ip service set telnet disabled=yes
-/ip service set www address=10.40.0.0/16,100.96.0.0/12
-/ip service set winbox address=10.40.0.0/16,100.96.0.0/12
-/ip service set api address=10.40.0.0/16,100.96.0.0/12
+/ip service set www available-from=10.40.0.0/16,100.96.0.0/12
+/ip service set winbox available-from=10.40.0.0/16,100.96.0.0/12
+/ip service set api available-from=10.40.0.0/16,100.96.0.0/12
 /ip service set api-ssl disabled=yes
 
 {% if obj.name == "crs326-core" %}
@@ -124,9 +128,19 @@
 {% endfor %}
 /ip dhcp-server option add code=6 name="dns 1.1.1.1" value=0x01010101
 
-# [6] DNS — Upstream aktuell PLAIN 1.1.1.1. DoH-Cloudflare-Gateway ist offener TODO
-#     (core hat kein CA-Bundle -> verify-doh-cert nicht moeglich), s. TP21.1.
-/ip dns set allow-remote-requests=yes mdns-repeat-ifaces=vlan10,vlan20,vlan40,vlan30,vlan90 servers=1.1.1.1
+# [6] DNS — DoH zum Cloudflare-Gateway, MIT Zertifikatspruefung (TP23 Stufe 1,
+#     scharf seit 2026-08-18; schliesst TP21.1 TODO 1).
+#     `servers=1.1.1.1` BLEIBT als Bootstrap stehen: RouterOS loest den
+#     DoH-Hostnamen selbst darueber auf, sonst Henne-Ei. Alles andere geht
+#     ueber DoH.
+#     Die frueher hier notierte Begruendung "core hat kein CA-Bundle" war zu
+#     pessimistisch: es braucht kein Bundle, sondern genau EINEN Root. Die Kette
+#     ist Leaf -> GTS WE1 -> GTS Root R4, importiert ist nur R4 (~1 KB, gueltig
+#     bis 2036) — entscheidend bei 2,8 MB freiem Flash.
+#     Der Import selbst steht bewusst NICHT im Template: er braucht die Datei
+#     auf dem Geraet und ist ein einmaliger Bootstrap, kein Sollzustand.
+#     Artefakt: routeros/tp23-stufe1-doh-core.rsc
+/ip dns set allow-remote-requests=yes mdns-repeat-ifaces=vlan10,vlan20,vlan40,vlan30,vlan90 servers=1.1.1.1 use-doh-server=https://px35ynlol3.cloudflare-gateway.com/dns-query verify-doh-cert=yes
 
 # Kanonischer Mgmt-Nummernplan (User-Bestaetigung 2026-08-13, verbindlich):
 #   core .99.1 | branch .99.2 | ap1 .99.11 | ap2 .99.12