UPGRADE IP 9 verfügbar!
Timberwolf VISU jetzt mit NEUEM Layout Editor
Freie Anordnung, Reihenfolge und Größe der Widgets - viele weitere Verbesserungen
Infos im Wiki: https://elabnet.atlassian.net/l/cp/06SeuHRJ

NEU! Insider & Leistungsmerkmale FÜR ALLE freigeschaltet
Damit kann nun jeder das Upgrade vornehmen und VISU & IFTTT testen. Alle Info hier: viewtopic.php?f=8&t=5074

[Beantwortet] Kopplung zweier entfernter TWS mittels MQTT über Kunden VPN möglich?

Wissen, Planung & Diskussion zur MQTT Unterstützung im Timberwolf Server.
Stellt uns hier Eure MQTT Projekte und Ideen vor.
Forumsregeln
  • Denke bitte an aussagekräftige Titel und gebe dort auch die [Firmware] an. Wenn ETS oder CometVisu beteiligt sind, dann auch deren Version
  • Bitte mache vollständige Angaben zu Deinem Server, dessen ID und dem Online-Status in Deiner Signatur. Hilfreich ist oft auch die Beschreibung der angeschlossener Hardware sowie die verwendeten Protokolle
  • Beschreibe Dein Projekt und Dein Problem bitte vollständig. Achte bitte darauf, dass auf Screenshots die Statusleiste sichtbar ist
  • Bitte sei stets freundlich und wohlwollend, bleibe beim Thema und unterschreibe mit deinem Vornamen. Bitte lese alle Regeln, die Du hier findest: https://wiki.timberwolf.io/Forenregeln
Antworten

Ersteller
Robosoc
Reactions:
Beiträge: 1876
Registriert: Di Okt 09, 2018 9:26 am
Hat sich bedankt: 635 Mal
Danksagung erhalten: 775 Mal

Kopplung zweier entfernter TWS mittels MQTT über Kunden VPN möglich?

#1

Beitrag von Robosoc »

Ich spiele gerade ein wenig mit MQTT Kopplungen. Im Video erklärt StefanW. ja eine Kopplung von drei entfernten TWS über einen MQTT-Broker im Internet. Das habe ich auch soweit verstanden und die zusätzlichen externen Kosten scheinen ja sehr gerin. Aber rein interessehalber habe ich mir jetzt die Frage gestellt, ob man nicht relativ einfach eine VPN Verbindung von einem TWS zum Kunden-VPN des anderen TWS aufbauen könnte? Dafür gibt es doch wahrscheinlich Open-VPN Clients für den Portainer, die sich auch nach einem sporadischen Verbinungsabbruch automatisch erneut verbinden...order?

Spricht etwas gegen eine solche Lösung?
VG, Sven - TWS 950Q ID:335 & 291, VPN offen, Reboot OK

blaubaerli
Reactions:
Beiträge: 2308
Registriert: Sa Sep 15, 2018 10:26 am
Wohnort: Kerpen
Hat sich bedankt: 884 Mal
Danksagung erhalten: 677 Mal

#2

Beitrag von blaubaerli »

Hi Sven,

du musst bei der Definition der MQTT-Subsysteme auf den beteiligten Wölfen ja eine Zieladresse nebst Port zur Erreichung einer gemeinsam nutzbaren MQTT-Broker-Instanz hinterlegen.

Stellt sich dann zunächst die Frage, wo diese gemeinsam genutzte Broker-Instanz sinnvoll liegen soll. Die kannst du zwar von der Theorie auf einen deiner eigenen Wölfe platzieren, ob das aber sinnvoll ist, kann man diskutieren. Fällt dieser Wolf aus, oder ist das LAN mit diesem Wolf von aussen via WAN nicht erreichbar, können alle beteiligten Wölfe den MQTT-Broker nicht erreichen und der Ausfall generiert Störungen in Anlagen, die nicht zwingend betroffen wären. Bist du "nur" mit zwei zu koppelnden Wölfen unterwegs, ist das womöglich wieder zu vernachlässigen, weil es immmer nur bilaterales Problem ist. Aber wie man ja in den letzen Tagen lesen konnte, geht die Tendenz hier ja mitunter schon zum Drittwolf :handgestures-thumbupright: :laughing-rolling:

Ich habe mich mit Open-VPN-Clients für Portainer selbst noch nicht befasst. Es stellt sich aber die Frage nach dem IP-Routing. Wenn du im Setup vom MQTT-Subsystem einen Broker mit einer IP-Adresse ansprechen möchtest, der hinter einer VPN-Strecke liegt, dann muss der Request seinen Weg zunächst in den Eingang zum lokalen Tunnelende finde. Das ist dann der Punkt wo ich im Moment die Schwierigkeit sehe. :confusion-scratchheadyellow:

Alternativvorschlag...: Ich habe in den von mir betreuten LANs Router im Einsatz die untereinander VPN-Verbindungen herstellen und auch dauerhaft halten können. D.h. der Wolf hat als Defaultgateway immer den lokalen Router als ersten Kommunikationspartner. Durch die Auswahl der korrekten Ziel-IP-Adresse leitet dein lokaler Router den Traffic dann via VPN in das definierte andere beteiligte LAN. Das ist dann ganz egal, woher der Ursprung des Requests im LAN kommt, egal von welchem Teilnehmer.

Beste Grüße
Jens
wiregate1250 & timberwolf168 (2600er), VPN offen, Reboot nach Vereinbarung

Ersteller
Robosoc
Reactions:
Beiträge: 1876
Registriert: Di Okt 09, 2018 9:26 am
Hat sich bedankt: 635 Mal
Danksagung erhalten: 775 Mal

#3

Beitrag von Robosoc »

blaubaerli hat geschrieben: Sa Nov 06, 2021 3:53 pm Es stellt sich aber die Frage nach dem IP-Routing. Wenn du im Setup vom MQTT-Subsystem einen Broker mit einer IP-Adresse ansprechen möchtest, der hinter einer VPN-Strecke liegt, dann muss der Request seinen Weg zunächst in den Eingang zum lokalen Tunnelende finde. Das ist dann der Punkt wo ich im Moment die Schwierigkeit sehe. :confusion-scratchheadyellow:
Ich auch. Mein Gedanke war Folgender:

Mir geht es wirklich nur um die Verbindung zwischen zwei TWS, wobei einer als Zentrale gilt und der andere als Abgesetzt oder Entfernt. Auf dem Entfernten wärde der MQTT-Broker und der VPN-Server (Kunden-VPN Zugang).

Wenn ich auf meinem Windowsrechner Zuhause (also im LAN des ersten TWS) eine VPN-Verbindung mittels Windows Open-VPN Client zum zweiten, enfernten TWS aufbaue, dann kann ich anschließend von dieser Maschine (Win-Rechner) aus auf beide TWS-Weboberflächen zugreifen.

Wenn ich also nun von einem TWS mit Container Open-VPN-Client aus die VPN-Verbindung aufbaue ( ich habe auch noch nicht nach einem Container gesucht, ist ja bisher nur eine theoretische Sache in meinem Kopf), dann müsste doch diese Maschine (also dieser TWS) auf beide TWS-Weboberflächen bzw. MQTT-Broker zugreifen können...zumindest solange, wie kein MacVLAN aktiviert ist. Mit MacVLAN braucht es dann vermutlich wirklich einen Router, das würde ich als Hardcore-Laie auch erstmal so sehen.

Beispiel Anwendungsfall den ich im Kopf habe:
In meinem Fall kam mir folgender Gedanken: Irgendwann möchte ich mir eine "Grafana-Kiosk-Ansicht" aufgebaut haben, die als Startseite meines Browsers fungieren soll. Dabei schalten im Kioskmodus von Grafana 4-5 Statusseiten rollierend durch. Eine davon könntem ich zukünftig über den Status meines Ferienhauses informieren.

Ich weiß, dass das für kleines Geld schon mit den im Video genannten Online-Brokern möglich wäre...aber ich habe mich halt einfach gefragt, warum muss ich überhaupt auf etwas Externes im Netz setzen, welchen Vorteil bietet mir das? Mir schienen die bereits vorhandenen Möglichkeiten doch schon fast auszureichen ....allerdings nutze ich tatsächlich MacVLAN.
VG, Sven - TWS 950Q ID:335 & 291, VPN offen, Reboot OK

StefanW
Elaborated Networks
Reactions:
Beiträge: 9689
Registriert: So Aug 12, 2018 9:27 am
Wohnort: Frauenneuharting
Hat sich bedankt: 4831 Mal
Danksagung erhalten: 7633 Mal
Kontaktdaten:

#4

Beitrag von StefanW »

Hallo Sven,

es ist heute sehr üblich geworden, dass sich zwei (oder mehr) Systeme, die sich miteinander verbinden, sich über einen Server im Internet "abstützen". Einfach weil letzteres eine stabile Größe ist.

Wenn Du zwei oder mehr Handys im gleichen Universum irgendwie koppelst für das Sharen von Einstellungen, der Zwischenablage usw. dann geht das immer über eine Cloudkomponente.

Mehrere Standorte untereinander über VPN zu verbinden kann man machen, ist aber wegen dynamischer IPs immer eine Herausforderung, die sicher nicht jahrelang wartungsfrei laufen wird.

Wir sind ein Unternehmen, das mit Einrichtung und Management von VPNs groß geworden ist und nichts liegt uns näher, aber ich rate eher zur Lösung über einen externen gemanagten MQTT Broker dafür, weil mit das wartungsärmer erscheint.

Wissen, was besser ist, tut man immer erst nach jahrelangem Betrieb.

lg

Stefan
Stefan Werner
Product Owner für Timberwolf Server, 1-Wire und BlitzART
Bitte WIKI lesen. Allg. Support nur im Forum. Bitte keine PN
Zu Preisen, Lizenzen, Garantie, HW-Defekt an service at elabnet dot de

Link zu Impressum und Datenschutzerklärung oben.
Antworten

Zurück zu „MQTT“