TP28: ap3 (cAP ax) live als CAP, ap1 funkstill, Compliance 130/130 ueber 5 Geraete
Der dritte Access-Point laeuft: 10.40.99.13 auf vlan99, Uplink ether1 -> core ether21, reiner CAP unter crs326-core, Kanaele 5180/ax/Ce/I und 2437/ax (ch6) -- am Geraet nachgemessen, nicht aus dem Plan abgeschrieben. Der Kanalplan stammt aus TP25 vom 2026-08-24; mein erster Entwurf hatte ihn neu erfunden und waere bei ch1 statt ch6 gelandet. Lehre: den TP-Body lesen, nicht nur den Quick-Index. ap1 hat bewusst KEINE Provisioning-Regel mehr: es steht bis zu seinem Umzug ans Sideboard direkt neben ap3 und wuerde auf 5180 kollidieren. Geraet bleibt erreichbar, die Objekte ch-*-ap1 / cfg-main-*-ap1 bleiben fuer den Umzug stehen. Bring-up in zwei Phasen ueber ein Patchkabel ap3 ether2 -> core ether22, weil ueber ether1 nichts ging (s.u.). Loop-Schutz: ether21 war waehrend Phase 1 abgeschaltet und wurde im selben Befehl gegen ether22 getauscht. RouterOS 7.20.8 -> 7.24.1 plus RouterBOOT (zwei Reboots, TP27-Kriterium erfuellt). Die anderen vier stehen auf 7.24 -- die Angleichung ist ein eigener Durchgang, der Core-Reboot ist ein Standort-Ausfall. Nautobot: DeviceType "cAP ax", Device ap3 mit 16 Interfaces, primary_ip4, secrets_group, ConfigContext 5g=ch36 2g=ch6 extra_ports=[]. Nebenkorrektur: ap1 stand auf "Wohnzimmer Sideboard", steht physisch aber in Technik UG (User-Bestaetigung). Sechs Funde, alle als Gotcha in CLAUDE.md und im Handoff: - ether1 ist am Werksgeraet WAN: Discovery aus, Input-TCP verworfen, ICMP aber erlaubt. Es pingt, und das liest sich wie "erreichbar". MikroMCP hilft nicht -- Port 80 ist zu. - pvid ist Ingress, tagged/untagged ist Egress. Ein Lease hing ewig auf "offered", weil der ACK getaggt rausging und ein Werksgeraet das nicht versteht. - `cap enabled=yes` reicht nicht: jedes Master-Radio braucht configuration.manager=capsman, sonst bietet der CAP seine Radios gar nicht an -- state=Ok, radio-Tabelle leer. - Ein Geraet ohne secrets_group erzeugt eine LUECKE, keine Fehlermeldung: Backup scheitert still, keine Compliance-Eintraege, Zahl bleibt unauffaellig bei 104/104. Eine gleichbleibende Compliance-Zahl nach dem Hinzufuegen eines Geraets ist ein BEFUND. - CAPsMAN verteilt keine Login-Passwoerter, nur WLAN-PSKs. Der Geraete-Login ist eine lokale DB pro Geraet; das einheitliche Admin-PW ist eine Konvention von Hand. - Firewall-Regelnummern aus `print where` sind Handles, keine Positionen. Beweis ist der Zaehler, nicht die Zahl. Abnahme: 3 CAPs state=Ok, VAP-Satz vollstaendig und running, 20 IOT-Clients auf ap3 mit 0 % Ping-Verlust ueber VLAN30 (bewusst nicht ueber die Registration-Table abgenommen), Compliance 130/130 / 0 Drifts, Core-Temp-Pfad restlos abgeraeumt. Offen: TP25-Messrunde (braucht Rundgang), PW-Rotation TP30, MikroMCP-Neustart. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
@@ -64,6 +64,15 @@
|
||||
# Das Objekt traegt bewusst KEINE vlan-id: die liefert der Manager pro VAP.
|
||||
/interface wifi datapath add name=dp-caps-slaves bridge=bridge comment="TP28-fix: bridge fuer CAPsMAN-Slave-VAPs"
|
||||
/interface wifi cap set enabled=yes discovery-interfaces=vlan99 slaves-datapath=dp-caps-slaves
|
||||
# 🔴 `cap enabled=yes` REICHT NICHT. Jedes Master-Radio muss zusaetzlich selbst auf
|
||||
# `configuration.manager=capsman` stehen, sonst BIETET der CAP seine Radios dem
|
||||
# Manager gar nicht an. Symptom (2026-08-30 live aufgeschlagen): `remote-cap print`
|
||||
# zeigt `state=Ok`, aber `/interface wifi radio print` am Manager listet fuer dieses
|
||||
# Geraet NICHTS -- und weil die Provisioning-Regel dann nicht matcht, sucht man den
|
||||
# Fehler in der radio-mac statt an dieser Stelle. ap1/ap2 tragen es seit dem
|
||||
# TP28-Cutover, im Werkszustand ist es leer (= local).
|
||||
/interface wifi set [find name=wifi1] configuration.manager=capsman
|
||||
/interface wifi set [find name=wifi2] configuration.manager=capsman
|
||||
|
||||
# --- (6) ZULETZT scharf schalten. Vorher waere der Rest der Datei nicht angekommen. ---
|
||||
/interface bridge set [find name=bridge] vlan-filtering=yes
|
||||
|
||||
36
routeros/tp28-ap3-service-accounts.rsc
Normal file
36
routeros/tp28-ap3-service-accounts.rsc
Normal file
@@ -0,0 +1,36 @@
|
||||
# =====================================================================================
|
||||
# ap3 — dedizierte Service-Accounts nachziehen. TP28-Nachtrag, 2026-08-30.
|
||||
#
|
||||
# BEFUND: nach dem Bring-up rendert Golden Config die intended config fuer ap3 sauber,
|
||||
# aber der BACKUP-Job scheitert -- Nautobot kommt per SSH nicht auf das Geraet. Ursache
|
||||
# ist kein Netz- und kein Firewall-Problem: ap1/ap2/core/branch tragen seit TP-PWD
|
||||
# (2026-08-23) dedizierte Service-Accounts `nautobot` und `ha`, ein Werksgeraet hat nur
|
||||
# `admin`. Ohne den User gibt es kein Backup, ohne Backup keine Compliance-Eintraege --
|
||||
# und die Gesamtzahl bleibt unauffaellig bei 104/104, weil ein Geraet ohne Ergebnisse
|
||||
# eben auch keine Drift meldet. 🔴 Merkregel: eine gleichbleibende Compliance-Zahl nach
|
||||
# dem Hinzufuegen eines Geraets ist ein BEFUND, kein Erfolg.
|
||||
#
|
||||
# Policies 1:1 von ap1 uebernommen (live gelesen, nicht abgeschrieben):
|
||||
# grp-ha = read,test,api,rest-api + alles andere explizit aus
|
||||
# grp-nautobot = ssh,read,write,test,sensitive + alles andere explizit aus
|
||||
# (write, weil Golden Config auch deployen koennen muss)
|
||||
#
|
||||
# `__HA_PW__` / `__NB_PW__` sind PLATZHALTER. Die echte Datei wird zur Laufzeit aus
|
||||
# ~/.secrets/credentials.env (MIKROTIK_HA_PASS / MIKROTIK_NAUTOBOT_PASS) ins Scratchpad
|
||||
# generiert und danach geloescht -- die Werte stehen nie in diesem Repo.
|
||||
# =====================================================================================
|
||||
|
||||
:if ([:len [/user group find where name="grp-ha"]]=0) do={
|
||||
/user group add name=grp-ha policy=read,test,api,rest-api,!local,!telnet,!ssh,!ftp,!reboot,!write,!policy,!winbox,!password,!web,!sniff,!sensitive,!romon
|
||||
}
|
||||
:if ([:len [/user group find where name="grp-nautobot"]]=0) do={
|
||||
/user group add name=grp-nautobot policy=ssh,read,write,test,sensitive,!local,!telnet,!ftp,!reboot,!policy,!winbox,!password,!web,!sniff,!api,!romon,!rest-api
|
||||
}
|
||||
:if ([:len [/user find where name="ha"]]=0) do={
|
||||
/user add name=ha group=grp-ha password="__HA_PW__" comment="TP-PWD 2026-08-23: dedizierter Service-Account"
|
||||
} else={ /user set [find name="ha"] group=grp-ha password="__HA_PW__" }
|
||||
:if ([:len [/user find where name="nautobot"]]=0) do={
|
||||
/user add name=nautobot group=grp-nautobot password="__NB_PW__" comment="TP-PWD 2026-08-23: dedizierter Service-Account"
|
||||
} else={ /user set [find name="nautobot"] group=grp-nautobot password="__NB_PW__" }
|
||||
|
||||
:log info ("tp28-ap3: service-accounts, users=" . [:tostr [:len [/user find]]] . " groups=" . [:tostr [:len [/user group find]]])
|
||||
39
routeros/tp28-ap3-werksreste.rsc
Normal file
39
routeros/tp28-ap3-werksreste.rsc
Normal file
@@ -0,0 +1,39 @@
|
||||
# =====================================================================================
|
||||
# ap3 — die drei Werksreste abraeumen, die die Compliance nach dem Bring-up gemeldet hat.
|
||||
# TP28-Nachtrag, 2026-08-30.
|
||||
#
|
||||
# Befund aus dem ersten Compliance-Lauf MIT ap3 (127/130):
|
||||
# ip-dns extra -> defconf-Eintrag router.lan -> 192.168.88.1 (die alte
|
||||
# Werks-LAN-IP, die es seit Phase 2 gar nicht mehr gibt)
|
||||
# ip-firewall-filter extra -> 11 defconf-Regeln. Ein reiner AP routet nicht, hat also
|
||||
# keine forward-Kette zu schuetzen; der Mgmt-Zugang haengt
|
||||
# an /ip service, nicht an der input-Kette (TP26).
|
||||
# ip-service missing -> die Haertung war nie gesetzt
|
||||
#
|
||||
# 🔴 `[find !dynamic]` waere ein SYNTAXFEHLER -- korrekt ist `[find where !dynamic]`.
|
||||
# Und Syntaxfehler schlagen beim PARSEN zu, `on-error` faengt sie NICHT. Symptom:
|
||||
# kein Fehler im Log, keine Wirkung, Plan meldet trotzdem Erfolg. (TP26, 2026-08-17.)
|
||||
# 🔴 Das Filtern auf `!dynamic` ist zusaetzlich noetig, weil `remove [find]` auch die
|
||||
# dynamische "special dummy rule to show fasttrack counters" erfasst -- RouterOS
|
||||
# verweigert deren Entfernung, das GESAMTE Kommando wirft, und es wird NICHTS entfernt.
|
||||
#
|
||||
# ⚠️ Kein Lockout-Risiko: `available-from=10.40.0.0/16` deckt alle BF-VLANs ab, also
|
||||
# auch den Mgmt-Weg ueber vlan99 und die Nautobot-Quelle 10.40.20.30.
|
||||
# =====================================================================================
|
||||
|
||||
# [1] /ip service haerten (Soll aus dem GC-Template, platform-weit)
|
||||
/ip service set ftp disabled=yes
|
||||
/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 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
|
||||
|
||||
# [2] defconf-Firewall abraeumen (TP26-Muster, identisch zu ap1/ap2)
|
||||
:do { /ip firewall filter remove [find where !dynamic] } on-error={ :log info "tp28-ap3: firewall-remove warf" }
|
||||
|
||||
# [3] defconf-DNS-Eintrag auf die tote Werks-IP
|
||||
:do { /ip dns static remove [find where address="192.168.88.1"] } on-error={ :log info "tp28-ap3: dns-remove warf" }
|
||||
|
||||
:log info ("tp28-ap3-werksreste: fw-statisch=" . [:tostr [:len [/ip firewall filter find where !dynamic]]] . " dns-static=" . [:tostr [:len [/ip dns static find]]])
|
||||
Reference in New Issue
Block a user