Christoph Emsenhuber
1006f91e6a
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>
40 lines
2.4 KiB
Plaintext
40 lines
2.4 KiB
Plaintext
# =====================================================================================
|
|
# 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]]])
|