MikroTik über LBS steuern | Edomi

[saegefisch]

Hi Urknall,
danke Dir; die meisten Seiten im MT-Wiki hatte ich auch schon gesehen - aber weder pim noch igmp-proxy findet sich (mehr) unter /routing. Daher passen die Beispiel auch nicht und daher auch meine Frage hier...

Was ich bisher verstanden habe: MT kann beides und IGMP-Proxy ist das einfachere Verfahren, aber eben auch nur für einfache Fragestellungen. PIM ist wohl die "dickere" Lösung für jede Fragestellung mit multicast.

Ob SONOS und meine Energymeter schon über IGMP-Proxy abbildbar sind oder vielleicht nur letzteres und SONOS PIM benötigt, weiß ich noch nicht, aber eine Lösung zu finden ist mein Ziel für dieses WE. Gerade SONOS dürfte auch andere interessieren: SONOS-Controller (iphone, Android, edomi) im internen VLAN, SONOS-Clients im Medien-VLAN.
https://forum.mikrotik.com/viewtopic.php?t=101244

Ab morgen gehe ich testen und forschen...

[Janncsi]

Ja, das Problem, welches du mit Sonos hast, habe ich mit Denon Heos! Wenn ich im Vlan des Heos bin mit dem Handy lässt sich alles steuern. Bin ich im Vlan der eigentlichen Clients, lässt es sich nicht bedienen. Ansonsten können aber Teilnehmer beider Vlans ohne Probleme miteinander kommunizieren...

Mir fehlt leider aktuell, da ich an der Visu dran bin, die Zeit mich um das Thema zu kümmern, aber irgendwo scheint ja ein systematisches Problem zu herrschen?!

[saegefisch]

Wir bekommen das schon hin. Systematisch ist es auf jeden Fall. Und das ist gut so, weil man dann systematisch auch Lösungen wird finden können...

ich bin zuversichtlich...hinsichtlich deiner schönen visu (ich fand auch das Blau am besten) und auch für multicast mit VLAN...

[Janncsi]

Och danke :-D

Ich hab aber mittlerweile einen Anwendungsfall, durch den ich schon jetzt weiß, dass ich bald wieder ans Thema Netzwerk muss....hab noch einen Intel NUC mit zwei Ethernet-Anschlüssen und ich will hier Mal schauen, inwiefern ich ohne Zusatzhardware ne DMZ aufgebaut bekomme und den NUC zeitgleich auch als normalen Client im Netzwerk halten kann....

Was mich grundsätzlich wundert ist, dass unsere beiden Herangehensweisen unterschiedlich sind, wir am Ende aber ein ähnliches Fehlerbild haben, sprich wir Netzwerkteilnehmer in zwei Vlans haben, die nicht miteinander kommunizieren können, obwohl es andere Teilnehmer können...

[saegefisch]

Erster Fortschritt: Die fehlenden Optionen PIM und IGMP-Proxy im Menü Routing bekommt man, wenn man das bei im MikroTik Download für sein Gerät(!) das passende "extra Packages"-ZIP herunter lädt, das darin enthaltene multicast-package entpackt und im MT per "files" hochlädt. Dann reboot, damit es in den System -> Packages auch erscheint/aktiviert werden kann. Damit steht nun PIM und IGMP-Proxy zur Verfügung.

Jetzt passen auch die Beispiel im MT-Wiki... stay tuned...

[coliflower]

Zur Info, vielleicht für den einen oder anderen interessant:
Mikrotik - Lets Encrypt Zertifikate mit MetaROUTER Instanz auf dem Router erzeugen
https://www.administrator.de/content....php?id=355746

[coliflower]

Hat jemand einen empfehlenswerten, "leicht" verständlichen Link zum Thema "wAP auf https umstellen / Zertifikate" ?

DANKE vorab.

[jonofe]

Du könntest mit easy-rsa eine PKI erstellen. Dann ein Certificate erstellen. Das per File>Upload in den MikroTik laden und unter System>Certificates installieren.
Dann über IP>Services SSL aktivieren und das installierte Certificate auswählen. Wenn du dann noch das PKI Root Certificate (wird bei der easy-rsa Installation erzeugt) in deinen Browser als vertrauenswürdig lädst, dann sollte das sogar ohne Warnung funktionieren. Ich habe es so für OpenVPN gemacht, allerdings noch nicht für HTTPS im Webinterface.

[coliflower]

OK, danke, da muss ich mich grundsätzlich doch etwas in das Thema einlesen ...
Bei CAcert hätte ich ein User- und ein Server-Zertifikat ... Dort gäbe es auch noch Rootzertifikate der CAcert.
Wäre das etwas ähnliches wie das von dir genannte easy-rsa ?

[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.

[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...

[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.

[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]

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...

[Janncsi]

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