MikroTik über LBS steuern | Edomi

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

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

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

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

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.

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

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

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.

[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

[Janncsi]

Da der Thread sowieso zum Mikrotik-Allgemein-Thread "verkommt" muss ich hier einmal meine Frage einstellen...

Da bei mir immer mehr die Notwendigkeit einer DMZ aufkommt (ReverseProxy und private Cloud), aber auch eines Servers der Sonderaufgaben übernimmt im privaten Netz, hatte ich mir preiswert einen weiteren Intel NUC geschossen. Hier habe ich mir dann noch einen USB3.0-Gigabit-Ethernet-Adapter geholt, so dass dieser nun zwei Ethernetports hat und ich schon physisch DMZ und Heimserver auf einem Host nutzen kann.

Jetzt ist es so, dass ich mir zur Realisierung mit dem CRS125 seit Tagen Gedanken mache. Grundsätzlich könnte ich auf dem CRS den SFP-Port in zwei unabhängigen Switch-Gruppen nutzen und folgendes Blockschaltbild realisieren:

Netzwerk_Neu2.png Problematisch an dem Aufbau ist, dass ich jetzt schon weiß, dass mir Ports fehlen werden und ich früher oder später noch einen kleinen zusätzlichen Switch integrieren sollte. Die Konfigurationsbesonderheiten des CRS, gerade in Bezug auf Vlans, erschweren es mir zusätzlich immer wieder Tutorials nachzuvollziehen und der Frust wächst.

Nun ist meine Idee eines Aufbaus mit dem ich einen weiteren Router in die Struktur integriere. Vorteil wäre, dass ich hier mit dem hex POE arbeiten könnte und meinen übergroßen POE-Injektor (12 Ports, von denen ich max 3 nutze) gleich mit in Rente schicken kann. Hier habe ich zusätzlich noch eine deutlich potentere CPU...

Netzwerk_Neu.png

Was meint ihr, macht der zweite Aufbau mehr Sinn in Bezug auf Sicherheit, Pflege und Konfigurationsmöglichkeiten?

Ist meine Idee mit dem zweiten NIC überhaupt nötig oder hab ich hier unnötig Geld verbrannt?

Würde mich einfach mal interessieren, was ihr davon haltet...

[jonofe]

Ich würde keinen Rechner mit zwei NICs in die DMZ und ins Private Netzwerk hängen. Damit hebelst du die Sicherheit der DMZ komplett aus, denn auch wenn es im Router sauber inkl. FW getrennt wird, verbindest du die Netze hintenrum im NUC wieder. Wenn dein DMZ Rechner kompromittiert wird, ist der Angreifer direkt im privaten Netz. Nimm nen RPI für DMZ und den NUC als internen Server. Dann geht alles durch den Router und wird in der FW gesichert.

Vielleicht habe ich dein Bild auch nicht richtig verstanden ...

[saegefisch]

Solange es MT-Geräte sind, kannst Du meine Scripte mit Anpassungen nutzen; halbwegs unabhängig von der Konfig. Für die Firewall will ich demnächst auch ein Update liefern für VLAN und PIM/Multicast. Damit sollte Du Dir rasch eine Lösung im Texteditor bauen können und Dein Frust sich im Zaum halten lassen... Das ist m.E. die gute Nachricht.
Allerdings bleibt das Risiko, dass Dich "mein" Access-Port-Problem mit dem CRS ebenso trifft. Mein Workaround ist ja derzeit ein non-MT-managedSwitch und am RB nur Trunk-Ports - bis das Thema für mich aufgelöst ist. Bis dahin fehlen mir 5 Ports, die ich am RB fest eingeplant hatte. Wäre spannend zu sehen, ob es bei Dir geht - was ich Dir wünsche. Leider gab es dazu weder hier, noch in anderen Foren bislang klare Rückmeldungen. Ich habe für VLAN-AccessPorts das Vertrauen in die RB mit dem aktuellen Konzept verloren und werde - wenn ich wieder Lust darauf habe - die neuen VLAN-Lösung (seit V6.41) an der Bridge versuchen und hoffentlich damit saubere Access-Ports bekommen. Wenn es damit auch nicht geht, bleiben die RB im Gesamtbild ziemlich gut, aber der Glanz wäre für mich weg, wenn man CAPsMAN, VLAN und Access-Ports nicht in eine Kiste bekommt.

NIC: Kabel und HW lügen nicht... daher habe ich DMZ und alle anderen internen Serverdienste auf zwei HW getrennt, für den RevProxy reicht ja sicher ein dünnes 20€-Kistchen (bei mir soll es ein CubieBoard 2; Projekt steht noch vor mir), dass per USB aus dem Router versorgt wird. Bei einer HW habe ich immer Sorge, dass ich was in SW übersehen habe; ich will mir nicht für den "Luxus" des ReversProxys (statt VPN, wie bisher) aus Unwissenheit ein Loch in mein Konzept reißen. Wenn Du Fit bist mit derlei Konfigurationen auf einer HW - dann geht das vielleicht

Zur Konfig: In der 2. Lösung wäre der CRS "nur" noch manged Switch? hex PoE wäre das, was bei mir der RB3011 ist. Insgesamt halte ich Lösungen für sinnvoll, wo es genau nur eine zentrale Stelle gibt, in der das Netzwerk gelöst wird, der Rest sind transparente Switche, per CAP degradierte AP und zur Not noch mangedSwitch mit VLAN-Konfig. In der 1. Lösung könntest Du nach Bedarf auch einen kleinen einfachen oder mangedSwitch dahinter setzen. Bei der 2. Lösung hast Du gemäß Skizze auch noch 3 PoE-Ports frei. Wenn Dir die Ports dann reichen, ist die 2. Lösung doch okay.

just my 2 cents...

[Janncsi]

jonofe
Du hast das richtig verstanden und ich habe auch deine Antwort verstanden. Hatte bisher gedacht, dass ich das durch die zwei NICs trennen kann, aber anscheinend nicht...nun gut...n Raspberry hab ich notfalls noch irgendwo liegen...

saegefisch
Und das ist das leider: Die Skripte von dir funktionieren auf dem CRS nicht in vollem Umfang, da die Funktionsweise auf dem CRS durch den Switch-Chip wohl anders ist. Die Konfiguration findet in einem anderen Bereich aus...das Ergebnis am Ende ist das gleiche, aber der Weg leider anders. Ich nutze bereits die 6.41 und das erleichterte schon vieles, aber während auf allen anderen Routern ich alle Einstellungen im Bridge-Menü mache, muss ich einen Teil im Bridge-Menü, den anderen Teil im Switch-Menü erledigen...

Den CRS kann ich aber auch als reinen Switch nutzen...mit 14W Verbrauch und Gigabit auf allen Ports wäre das immernoch gut. Somit hätte ich die von dir vorgeschlagene Trennung, CRS als ManagedSwitch und den hex als reinen Router. Nach der Skizze hab ich übrigens nur einen Platz frei (2 Caps, einmal DMZ und einmal CRS)

Also was ich auf jeden Fall mitnehme ist, dass ich einen Raspberry für den ReverseProxy nutze (warum kann der Mikrotik das eigentlich nicht :-P) und den Rest im ganz normalen Netzwerk laufen lasse...

[saegefisch]

wenn der hex PoE die gleiche Oberfläche hat, wie die hAP oder der RB3011, dann wäre das noch ein Argument für Lösung 2... dann sollten die Scripte im wesentlichen funktionieren. Bei mir läuft das seit einiger Zeit ganz gut; im wesentlichen habe ich nur an Firewall, PIM und festen IP-Adressen (DHCP, DNS) gearbeitet; der Rest ist nahezu unverändert zum letzten Bereitstellen.
Darüber hinaus: Ich vermute mal, dass auch für den CRS mit 6.41 das Ziel von MiroTik ist, die VLANs über die Bridges einzurichten. Das sollte dann auch mit Lösung 1 gehen.

Ich wünschte, ich könnte Dir unbefangen zu etwas raten - aber letztlich habe ich auch nur 90% meines konzeptionierten Ziels erreicht (mit dem MT als zentrale Lösung für alle Netzwerk-Themen) und habe in der letzen Nacht auch ein wenig die Lust verloren (nach unfassbar vielen Tagen und Nächten). Seit heute mache ich erst einaml wieder edomi...

[Janncsi]

Hatte ich damals auch zwischendurch gemacht, da ich nicht weiter kam und irgendwann machte es Klick...

Momentan erkenne ich den Weg beim CRS noch nicht....man macht zwar nix mehr mit der Master-Port-Konfiguration, aber gänzlich auf Bridge-Ebene wird es doch nicht implemenotiert
ach, was soll's...ich bestell einfach Mal n hex POE...kostet nahezu ja nix und ich hab gleichzeitig auch ne Testumgebung :-D