Test Adapter owntracks v1.0.x Github
-
So ich habe mein Beitrag gefunden, wenn Du soviel schreibst wie ich, dann weiß man dass man mal was vorgestellt hat, aber musst ewig suchen. Ich beginne nun Lesezeichen für meine eigenen Beiträge zu machen :
https://forum.iobroker.net/topic/23078/multihost-slave-zu-viel-traffic/10
Die portmapper Geschichte brauchst Du nicht, sondern einfach die mqtt ssl verbindung.
Die mosquitto Installation selbst ist easy - brauchst nur mit
sudo apt install mosquittoinstallieren.
Wie Du die Bridge und die Zertifikate erstellst habe ich aus den Videos von Steve benutzt:
http://www.steves-internet-guide.com/mosquitto-bridge-configuration/
und hier die Zertifikate für die mqtt - ssl kommunikation:
http://www.steves-internet-guide.com/mosquitto-tls/Wie Du das Client Zertifikat in die owntracks importierst - siehst Du hier:
https://owntracks.org/booklet/features/tlscert/Da ich owntracks auf IOS laufen habe schickst Du Dir das Client Zertifikat als Mail mit einem Anhang und der Endung:
.otrpunter dem Link findest Du auch ein Anleitung wie Du unter Android das Zertifikat importierst.
In den Settings - kann ich Dir nur zeigen, wie die Einstellungen dann unter IOS aussehen:
Die ganzen Informationen kommen dann über den mqtt-Adapter als Client in den iobroker:
Damit solltest Du die wesentlichen Informationen haben.
Testen tust Du das Ganze natürlich indem Du einfach das WLAN auf dem Handy abschaltest und Deinen Standort manuell aktualisierst.
-
Hallo,
danke für die ausführliche Antwort.
Habe aber eine Verständnisfrage.
Welche "Gefahr" wird mit dem weg über mosqitto gelöst?
Ich dachte das Sicherheitsproblem ist der offene Port mit dem man ins Heimnetz kommt. Den braucht man bei mosqitto ja auch.Der Vorteil ist also nur (nicht falsch verstehen, ist natürlich wichtig), dass der Datenverkehr nicht mitgelesen werden kann. In dem Fall Standortdaten (was anderes errichtet man unter dem Port von owntracks ja nicht)?
Die Sicht bezieht sich nur auf die Sicherheit der IT. Datenschutz ist natürlich auch wichtig.
Ist jetzt wirklich mein DAU-Gedanke.
-
@david-g Na es geht bei sicheren Zugängen nur um Verschlüsselung. Der Inhalt ist dabei unwichtig. Ob Du den Port für Dein VPN aufmachst oder den Port 443 zu HTTP Verschlüsselung oder eben mqtt Verschlüsselung ist dabei weniger entscheidend.
OK wenn Du das VPN direkt mit der FritzBox machst ist zwar das schon etwas sicherer.
Wenn Du das Problem mit dem offenen Port hast, dann kannst Du für die mqtt-Bridge natürlich eine eigene Maschine nehmen, die dann in er DMZ steht, so macht man das in der Regel und dann lässt man natürlich mit einer Firewall nur den Verkehr zwischen der mqtt Bridge zum mqtt Broker zu,
Also hier hast Du natürlich alle Möglichkeiten der Geräteabsicherung. Wenn Du aber eine Kommunikation über einen bestimmten Port verschlüsselst, ist der Vorteil ja nucht nur, dass man die Daten nicht mitlesen kann, sondern ein potentieller Angreifer ja gar nicht weiß, welche Daten von welcher App überhaupt über die Leitung gehen. Deshalb kann er anhand des Ports vielleicht vermuten, dass es sich um eine mqtt Kommunikation handelt und würde dann prüfen, ob der Broker irgendwelche Sicherheitslücken aufweist.
Letztlich muss aber den Telefon irgendwie mit Deinem iobroker oder mqtt arbeiten. Im Übrigen hast Du immer ein Problem, wenn die Verbindung von außen nach innen aufgemacht werden soll. Wie gesagt über ein VPN mit der FB bist schon gut abgesichert und ansonsten, wenn Du nochwillst, dann musst noch einen kleinen Raspberry in einer DMZ mit der mosquitto Bridge installieren, dann verbindet sich Dein Gerät auf jeden Fall erst mal mit einem anderen Gerät. Dann musst Du aber noch etwas in Hardware investieren!!!
Wenn Du um Netzwerksicherheit und DMZ wissen willst - mal wieder Wikipedia:
https://de.wikipedia.org/wiki/Demilitarisierte_Zone_(Informatik)
Hab auch gerade noch bisschen gegoogelt. Wenn Du die bridge auf einer extra Hardware kann man diese als Exposed Host in der FB deklarieren und ist ggf. noch extra abgesichert:
Hier mal ein entsprechender Artikel:
https://avm.de/service/wissensdatenbank/dok/FRITZ-Box-7590/131_DMZ-in-FRITZ-Box-einrichten/Sofern ich das aber verstanden habe - wird an dieses Gerät alle Ports nach außen freigegeben und Du musst halt quasi mit einer eigenen Firewall das ganze absichern
-
Danke für deine Erläuterungen.
Eine dmz ist natürlich was......Ich habe vor nem Monat oder so einen Artikel gelesen.
Hab ich eben nochmal raus gesucht.Cloudflare Argo & Access - Kein VPN und Port Forwarding
Das hat sich auch ganz interessant angehört.
Das Argo wäre hier dann wohl das Mittel der Wahl. -
@david-g Nun ich weiß nicht, ob Dein Problem damit gelöst ist. Die Verbindung vom internen Netz zum externen Netz also zur DMZ wird von einem Server von innen aufgebaut.
Wie das ganze auf der Client Seite aber aussieht, siehst Du nicht. Wenn das eine VPN Verbindung zwischen Handy und der Cloudfare Cloud aufbaust, hast Du in meinen Augen, was den Resourcenverbrauch betrifft nichts gewonnen.
Meine Lösung hat ja den Charme, dass nur dann eine Verbindung aufgebaut wird, wenn owntracks was sendet.
Wenn Du den Aufwand betreiben willst kauf Dir lieber einen Router/Switch mit intergrierter Firewall, der VLAN aufbauen kann.
Dann steckst die FritzBox in eigenes VLAN, eine Box mit der Mosquitto Bridge in ein VLAN als DMZ und das interne LAN als eigenes VLAN. -
Hab das so verstanden, dass der cloudflaretunnel vom raspberry zu cloudflare aufgebaut wird.
Das Handy kommuniziert über eine URL die mit cloudflare verbunden ist.
Oder hab ich das falsch verstanden?
-
Der Tunnel zum internen Netz ja - aber das Handy braucht mE eine App. Was soll denn eine URL da machen?
Also entweder habe ich was falsch verstanden, aber mE brauchst Du dann auf dem Handy eine dieser Apps:
https://apps.apple.com/us/app/1-1-1-1-faster-internet/id1423538627 (IOS)
oder
https://play.google.com/store/apps/details?id=com.cloudflare.onedotonedotonedotone&hl=de&gl=US (Android)aber ich habe mich natürlich habe ich mich damit nicht intensiv beschäftigt - aber eine URL an sich kann ich mir nicht vorstellen - im Handy kannst ja schlecht angeben, diese APP bitte das nutzen, diese APP was anderes nutzen. Also wird entweder alles zu einem VPN geleitet oder nicht (egal ob das mit Boardmitteln oder solcher Apps geht).
@david-g sagte in Test Adapter owntracks v1.0.x Github:
Hallo,
ich teste gerade auch den owntracks-Adapter.
Mir gefällt es, dass keine cloud genutzt werden muss.Allerdings tu ich mich noch was schwer mit, den Standort von unterwegs zu übermitteln.
Nun da ist doch die Verschlüsselung doch sinnvoll.
-Der Vorteil ist also nur (nicht falsch verstehen, ist natürlich wichtig), dass der Datenverkehr nicht mitgelesen werden kann. In dem Fall Standortdaten (was anderes errichtet man unter dem Port von owntracks ja nicht)?
Auch wenn Dir das 2 Post später dann wohl doch nicht mehr wichtig ist.
Über vpn wird das Smarthome leer gesaugt.
Mit einem Reserveproxy und sowas kenne ich mich absolut nicht aus.Einfach den Port an der Fritzbox aufmachen und weiterleiten ist denke nicht das sicherste?
Wie gesagt aus Sicherheitsgründen OK - aber ob das was an Deinem Resourcenverbrauch ändert - ist aus meiner Sicht eher zweifelhaft und das war doch Deine Hauptmotivation und nicht die Sicherheit zu verbessern.
Übrigens Reverseproxy - habe auch einen nginx laufen - geht auch, aber musst auch einen Port öffnen.
-
Habe noch keine Idee wie ich es mache und was mir wichtig ist.
Hab einfach alle Gedanken runtergeschrieben die ich habe um zu sehen ob mein Denken richtig ist.Wenn das mit Argo so ist, wie ich es verstehe, kann man es noch wunderbar für andere Dienste mit nutzen.
Habe dem Autor vom Artikel mal eine Mail geschrieben.
-
@Zefau @Jey-Cee Ich habe eben mal den Adapter installiert, erst direkt aus dem Adapterbereich in iobroker, aber da kam Version 1.0.0 mit integriertem MQTT-Client. Da meine Owntracks-Geräte aber alle Daten auf einen Mosquitto schieben und ich von dort auch Daten für den Owntracks-Recorder und das Frontent abgreife, war das wohl die falsche. Den 1.0.0-rc1 von @Zefau habe ich dann bei Github gefunden und der läuft, abgesehen von diversen Warnings wegen falscher Zustände von States und Foldern. Aber er läuft, mit loglevel auf error dann auch ruhig.
Aber, bevor ich da jetzt mehr investiere und Scripte und dergleichen anpasse: Wohin geht die Reise langfristig? Wird es in Zukunft nur noch die Version ohne MQTT geben, die direkt auf Daten von anderen Brokern zugreift, oder war das nur mal was zum Testen und es wird nur noch die Version mit integriertem MQTT-Broker weiterentwickelt? Beim 1.0.0-rc1 sind die jüngsten Änderungen immerhin schon 2 Jahre alt, während es beim "offiziellen" 1.0.0 "nur" 3-8 Monate sind.
Gruss, Jürgen
-
@wildbill ich bin nicht an der Entwicklung von Owntracks beteiligt und mir sind keine Pläne für diesen Adapter bekannt. Für mich sieht es aber nicht so aus als würde hier Entwicklung statt finden. Es werden lediglich Anpassungen vorgenommen um Lauffähig zu bleiben. Was, wenn der Adapter ohne Probleme läuft auch ausreichend ist.
Deine Aussage
@wildbill sagte in Test Adapter owntracks v1.0.x Github:
mit integriertem MQTT-Client.
widerspricht dieser Aussage von dir
@wildbill sagte in Test Adapter owntracks v1.0.x Github:
mit integriertem MQTT-Broker
Also was trifft jetzt zu?
-
@wildbill Den owntracks Adapter brauchst Du nicht. Nimm den mqtt-Adapter und konfiguriere den als Client für Deinen mosquitto und Du hast alle notwendigen owntracks Punkte - so mache ich das ja auch.
-
@jey-cee Sorry, ich dachte, Du wärst involviert, weil Du den alten Thread geschlossen und auf diesen verwiesen hattest.
Es gibt den Adapter in zwei Versionen. Einmal die 1.0.0 direkt auf Github, die bringt einen eigene MQTT-Broker mit. Und einmal die 1.0.0-rc1 im gleichen Repo, die @Zefau angepasst hatte, und die ihre Daten über einen MQTT-Client-Adapter ausliest. Und die läuft halt auch mit externen MQTT-Broker wie Mosquitto, was ich persönlich besser finde, da bei mir auch andere Tools auf die Daten zugreifen.
Die Version 1.0.0 wurde die letzten 3-8 Monate minimal angepasst, das letzte mal anscheinend von @apollon77 . Die (in meinen Augen bessere) 1.0.0-rc1 vor zwei Jahren das letzte Mal von @Zefau .
Deshalb meine Frage, ob es sich lohnt, hier Zeit reinzustecken, und vor allem welche Version langfristig präferiert wird und ob überhaupt.
Gruß, Jürgen -
@mickym Mir gefällt halt am Adapter, das ich die Daten so direkt im iobroker habe. Also direkt Datenpunkte, wer sich bei welcher Location befindet. Im Mqtt-Client habe ich sie ja schon drin, die bereitet die Version von @Zefau ja so schön auf. Im MQTT-Client habe ich nur die Json, die ich selbst zerpflücken müsste...
Wenn ich den Adapter mit integrierten Mqtt-Broker nehmen würde, habe ich die Daten ja nur im iobroker und nicht im Mosquitto, wo ich sie für den ot-recorder und das Frontend brauche.
Oder wie meinst Du genau?
Gruß, JürgenEDIT: Da ich mit Payload encryption arbeite, habe ich im MQTT-Client auch nur die verschlüsselten Daten. Die bekomme ich ohne Adapter also gar nicht ausgewertet...
-
@wildbill sagte in Test Adapter owntracks v1.0.x Github:
Deshalb meine Frage, ob es sich lohnt, hier Zeit reinzustecken, und vor allem welche Version langfristig präferiert wird und ob überhaupt.
Ich Denke diese Frage ist mehr oder weniger schon geklärt, da diese Änderung nie in den Hauptzweig eingeflossen ist. Wobei ich nicht erkennen kann warum nicht. Für mich sieht das kurz vor Fertig aus.
Und aus meiner Sicht macht es schon Sinn die Client Variante als Alternative zum Broker an zu bieten. -
@jey-cee Als Auswahl wäre natürlich TOP. Aber @Zefau hatte ja schon amals im alten Thread angedeutet, dass ihm irgendwie die Zeit fehlt, hier viel zu investieren.
Laufen tut er ja momentan im loglevel error, damit nicht zu viele Meldungen kommen. Nur ab und an steigt er kurz aus, wirft ein paar errors und startet dann wieder...
Gruss, Jürgen -
@wildbill Nun ich arbeite auch mit mqtt Encryption und habe auch für jedes Telefon einen Datenpunkt:
Falls Du die JSON Strings noch in eigene Datenpunkte haben willst - gibts einen NodeRed Subflow von mir.
Die owntracks Kommunikation zwischen Handy und MQTT ist bei mir ebenfalls verschlüsselt über die mosquitto Bridge und Zertifikat.
-
@mickym Das heisst, Du sammelst die Daten von den Geräten auch encrypted in Mosquitto und hast in Node-Red einen Flow laufen, der das entschlüsselt und die passenden Datenpunkte daraus erstellt? Das wäre natürlich auch TOP. Bevor ich lange suche, ist der Flow hier im Forum irgendwo?
Gruss, Jürgen -
@wildbill Die Entschlüsselung der Daten wird von mosquitto selbst vorgenommen.
Zwischen Handy und der mosquitto Bridge ist verschlüsselt. Der Broker greift verschüsselt auf die Bridge zu und entschlüsselt dabei . In dem Diagramm habe ich das mit Port 8883 markiert (verschlüsselte Kommunikation) und 1883 ist die entschlüsselte Kommunikation.
Das Ganze wird auch auf die owntracks topic begrenzt und gefiltert! - So dass nichts auf der Bridge verfügbar ist, was dort nicht sein soll.
Um aus JSONs eigene Datenpunkte zu machen mit NodeRed zu machen - siehe hier - ggf. muss man nun noch für die Folder Objekte seit dem admin5 noch das Skript von @fastfoot drüber laufen lassen.
Ansonsten macht der NodeRed Subflow aus jedem JS Objekt, JSON String etc. einzelne Datenpunkte:
https://forum.iobroker.net/topic/43856/json-string-oder-java-object-in-iobroker-struktur -
@mickym Jetzt verstehe ich. Du redest von der Verschlüsselung der Verbindung und bekommst im Mosquitto die Daten in lesbarer Form. Bei mir ist aber zusätzlich die Payload encryption aktiv. Die Daten kommen also nicht lesbar an sondern z.B. so:
{"_type":"encrypted","data":"zwulyo9ma+u41Kn.....E+Drvb68Wj448lzodHdk\/y68zDhuAxXvFCyolQD07Tm3Cogthbatgj6uN1......r6vTCNwY6WQNP7SQx+HX2ZIA2J+SAjURmOZIEH\/\/faqnIlCxQzM6Xo0TN34EHP.....39Z+DexylLCIlSXIKK6yiUChOxuka5bjAZx\/s1csjAexhrFiTzC6A6jM0.....oUrYkrFJCECoCpWRF8ztqXgECoVOgbMhX2t5H8tCglD6Vtza\/Thg.....braiA=="}Für den or-recorder und das Frontend kein Problem, die entschlüsseln das. Ebenso der Owncloud-Adapter, dort kann man den Encryption-Key auch eintragen. Nur denke ich, es wird schwer, selbst daraus was Lesbares zu machen?!
Gruss, Jürgen -
@wildbill Im Broker sind die Daten entschlüsselt auf der Bridge verschlüsselt.
Gut dann ist das keine Lösung.
Aber ich habe gesehen, dass es eine Node-Red Node gibt: https://flows.nodered.org/node/node-red-contrib-owntracks
Die nimmt als Input eine mqtt-In Node und man kann anscheinend ein preshared secret angeben zur Entschlüsselung. Vielleicht funktioniert es ja damit. Zusammen mit meinem Subflow könntest Du dann eigene Datenpunkte erstellen.
