MikroTik über LBS steuern | Edomi

[coliflower]

... für HTTPS im Webinterface.

Hallo André,

ich habe die PKI (als solche selbst, für die gesamte IT-Struktur bei mir) mal auf meine ToDo Liste geschrieben und die Zertifikate quick and dirty im AP erstellt und auf HTTPS umgestellt. Scheint zu funktionieren, es ist mir bis jetzt nichts negatives aufgefallen.

Das habe ich via Google gefunden - es müssen immer zwei Zertifikate erstellt werden, ein ROOT und ein für HTTPS (für die, die es wie ich, bis jetzt nicht wussten):

/certificate
add name=root-cert common-name=MyRouter days-valid=3650 key-usage=key-cert-sign,crl-sign
sign root-cert
add name=https-cert common-name=MyRouter days-valid=3650
sign ca=root-cert https-cert

/ip service
set www-ssl certificate=https-cert disabled=no
set www disabled=yes

[saegefisch]

Hi Boesi, danke für den Tipp. Das PDF hatte ich vor ein paar Tagen schon zur Hand... entweder habe ich es nicht verstanden oder es arbeitet mit dem IGMP-Proxy und der scheint mir nach meinem Verständnis leider nicht hinreichend für mehrere Multicast-Ströme aus unterschiedlichen Subnetzen (da dabei nur ein Upstream erlaubt)... daher schien mir PIM unumgänglich und für SONOS ging es ja auch ganz einfach: Interfaces eintragen, der Rest in der Firewall. Warum der/die anderen Multicast gar nicht funktionieren...lässt mich schon etwas verzweifeln... Möglicherweise muss im PIM mehr gemacht werden, wenn man unterschiedliche Routen bzw. Subnetze hat?

Das brauch' ich auf jeden Fall...
VLAN 10 <-> VLAN 30: Multicast SONOS Controller <-> SONOS Clients
VLAN 20 -> VLAN 30: Multicast SMA energymeter -> Linux-Rechner für Verarbeitung

Es gibt noch ein paar weitere Multicasts, aber die sind mir nicht so wichtig.

[Boesi]

Guten Abend,
Google doch mal nach Fiber7 Mikrotik Multicast.
Da beschreiben die Ihre Einrichtung für IPTV mit Multicast. Eventuell kannst Du daraus was für Dich erschließen.

[saegefisch]

Bleibt als derzeit letzte Baustelle das (für mich viel schmerzhaftere, weil edomi-relevante) Multicast-Thema: Mit PIM geht jetzt SONOS recht gut, aber der ganze PV-Zoo von SMA kommt einfach nicht durch. PIM sollte doch mehrere Multicasts können, nicht nur einen, oder? Was könnte noch der Grund sein, dass ich im Torch sekündlich Daten auf 239.12.255.254:9522 sehe, aber nichts davon in der firewall - da müsste es ja mit einer entsprechenden Regel - auch unabhängig von PIM - Pakete zählen...

Und: Ohne RP zum PIM wird das Log mit Warnungen geflutet. Habe als RP die Adresse 192.168.1.1 (Also die IP des RB im Managment-Netz) gewählt. Ist das richtig? Welche IP (wegen der VLANs sind es ja eine ganze Reihe) des RB sollte man als Rendezvous-Point wählen? Vielleicht liegt es ja daran; oder ist das egal?

Jemand mit PIM-Erfahrung an board? Mit mehreren verschiedenen Multicasts? Das Multicast-Thema dürfte im edomi-Umfeld eigentlich auch weitere System-Kommunikationen neben SONOS iund SMA betreffen...

[saegefisch]

Danke, André. Bis auf auf einen Punkt hatte ich es genau so... Bei mir unterscheiden sich Discoery Interface ("backbone-bridge") und Bridge ("WLAN-Bridge")... wenn es wieder einen Fehler gibt, werde ich daran mal arbeiten.

[jonofe]

Korrekt: 3 Caps, unabhängiges Booten ohne Funktionsbeeinträchtigung oder manuellen Eingriff möglich.

CapsMan:
Screenshot from 2018-01-15 18-18-19.png
Cap:
Screenshot from 2018-01-15 18-18-47.png

[saegefisch]

Es fällt schnell auf, da der CAP keine dauerhafte Verbindung aufbauen kann und damit das WLAN des AP fehlt. Im Log des Masters auch sofort in rot ersichtlich. Die Logs der hAP sind nicht rot, zeigen nur den ewigen Zyklus try-and-error.
Zunächst hatte ich es mit eigens zuvor generierten CA/Zertifikat und im CAPsMAN explizit ausgewählten versucht, dann kam der Fehler. Seit dem mit "auto" - nicht besser, aber auch nicht schlechter.

Und das wichtige von Euch beiden: Ihr habt gleichfalls >1 CAP und es geht. Dann muss es wohl an meiner Config liegen. Ich nehme an, dass Ihr auch mal den RB, mal die hAP getrennt voneinander neu gestartet habt. Oder hängen die alle per PoE am RB und gehen damit alle gemeinsam runter und wieder hoch?

Eure Rückmeldung: Das ist gut zu wissen - und ist trotzdem doof, dass es bei mir auftritt...

Vielleicht mal ein Screenshot von den beiden Fenstern "CAPsManger" (RB) und "CAP" (von einem hAP)? Ein Bild ist ja manchmal doch besser...

[Klaus007]

Hallo!

Dieses Phenomen hatte ich nur während ich an den Configs vom Capsmanager "rumgespielt" habe. Seit ca. 1,5 Jahren habe ich mich trotz unzähliger Updates und Reboots um den Capsmanager und seine Caps (9 Stück) nicht mehr zu kümmern brauchen.

[jonofe]

Verwendet ihr denn selbsterstellte Zertifikate oder die auto-generated vom CapsMan?
Wo taucht denn die Fehlermeldung auf? Vermutlich fällt mir das gar nicht auf, da ich da nicht täglich reinschaue.
Zumindest ein FW Upgrade inkl. Reboot ist aus reiner Funktionssicht bei mir problemlos auf 4 APs durchgelaufen.

[Janncsi]

Kann ich bestätigen, muss ich auch schon einmal machen, wenn ein Cap unerwartet ausgeschaltet würde.

[saegefisch]

Tatsächlich funktioniert es ganz wunderbar, wenn ich auf RB und alle hAP CAPsMAN/CAP disable, dann alle Zertifikate auf allen Systemen lösche und wieder enable - dann klappt das Provioning und Generieren der Zertifikate ganz wunderbar. Nur wenn ich einen hAP mal reboote, gibt es eben diesen Fehler. Das setzen CommonNames auf den beiden hAP habe ich jetzt mal versucht; erstaunlich ist, dass ich bei beiden hAP den selben CommonName des "KI"-Zertifikats eingeben muss; ich dachte, ich müsste die spezifischen "I"-Zertifikaten eintragen - aber damit gab es keinen provioning.

Mal schauen, ob es funktioniert, den ersten reboot hat's schon mal überlebt...

[jonofe]

Könnte daran liegen, wenn du die hAPs auch mit exakt denselben Zertifikaten provisionierst.
Man kann den CommonName aber auch unter CapsMan>CAP auf den Caps setzen. Habe ich aber noch nie versucht.
Normalerweise generiert der CapMan die Zertifikate für die CAPs und die werden bei der Anbindung transferiert.
Am besten mal testen, ob das explizite Setzen des CommonName auf dem hAP hilft.

[saegefisch]

Frage zu CAPsMAN: Hat jemand vergleichbare Fehler ("a valid certificate with the same common name...") im Log bzw. einen nicht mehr sauber startenden CAPsMAN, wenn amn z.B. einen hAP rebootet. Habe mir für den RB und die beiden hAP jetzt stop-/start-Scripte (stop: disable, dann Certifikate alle löschen | start: enable) gemacht, die ich jetzt über Andrés LBS orchestriert aus edomi heraus aufrufen würde: "RB stop -> alle hAP stop -> RB start -> alle hAP start".

Aber vorher die Frage: Hat jemand das gleiche Thema besser gelöst? Vielleicht braucht es die Scripte ja gar nicht.
Info: im CAPsMAN habe ich beide Zertifikaten auf "auto" stehen, in den hAP Certificate auf "request". Mit festen Zertifikaten hatte ich das gleiche Problem.

[saegefisch]

Update für das Thema Multicast SONOS für MikroTik: Nach Installation PIM Package nur die relevanten bridge-vlanxxx als PIM Interfaces anlegen und fertig. Der Rest in der FW. Mit diesen Werten geht bei mir Sonos jetzt - im wesentlichen aus dem Beispiel im folgenden Link:

# Multicast
# SONOS: [URL="https://forum.mikrotik.com/viewtopic.php?t=101244#p607236"]https://forum.mikrotik.com/viewtopic...101244#p607236[/URL]
add chain=forward action=accept dst-address=239.255.255.250 out-interface=!bridge-vlan020 comment="SONOS Multicast"
add chain=forward in-interface=bridge-vlan010 out-interface=bridge-vlan030 dst-port=1400,4444,4070 protocol=tcp comment="SONOS remote control to players"
add chain=forward in-interface=bridge-vlan030 out-interface=bridge-vlan010 dst-port=3400,3401,3500,4070 protocol=tcp comment="SONOS remote control from players"
add chain=forward in-interface=bridge-vlan030 out-interface=bridge-vlan010 dst-port=1900,1901,5353,6969 protocol=udp comment="SONOS UPnP Discovery"

Anmerkung:
* Abweichend vom Beispiel oben hat die DST-Adress bei mir in der UDP-Regeln nicht funktioniert; wenn man sie weg lässt, geht es. Falls jemand dazu was besseres hat: gerne!
* Abweichend vom Beispiel habe ich ein paar Ports von der Sonos-Seite zusätzlich notiert (spotify, Init).
* Die Einrichtung des geänderten WLAN wollte partout nicht aus dem anderen VLAN gehen, obwohl ich im Torch kein anderen Port mehr sah und auch bei SONOS nicht mehr steht (oder ich übersah). Daher: Für die Änderung des WLANs vom bisherigen in das media-VLAN musst ich einen PC/Laptop mit der Sonos-SW temporär ins gleiche Netzt hängen, dann klappte es sofort. Danach kann der wieder weg, die Steuerung der SONOS-clients im VLAN 30 klappt nun wunderbar aus meinen VLAN 10.
* Wenn man den Multicast aus anderen VLANs raushalten will, könnte man das wohl mit "=!Interface-List" in der ersten FW-Regel erreichen.

War mit PIM letztlich alles ganz einfach. Aus einem unerfindlichen Grund geht das selbe aber noch nicht mit meinen (noch viel einfacheren) SMA energymeter-multicast-Daten, in der FW schreit mich dort noch immer eine "0 Packets" an...

[jonofe]

easy-ca ist deine eigene CA. Wenn du schon ein SSL Zertifikat hast, dann kannst du das auch verwenden. Einfach in den MikroTik hochladen, einbinden und aktivieren.