Hallo!
Eins habe ich schon verstanden, dass ich bei der serverbasierten Gateway die gesamte Einstellung auf dem hconnect Server vornehme und die Konfigurationsdateien ebenso dort liegen.
Alle Anfragen vom Echo gehen erst zu Amazon Service, dann zu hconnect und zum Schluss in meine CCU?
Angefragt Werte werden dem umgekehrten Weg zurück gegeben.
Bei der lokalen Installationen gehen die Anfragen zum lokalen hconnect Server z.B. Pi und werden an die CCU lokalen Netzwerk weitergereicht?
Dann sollte doch die lokale Variante etwas schneller sein. Wenn ich das Gateway auf dem Pi laufen lasse, dann wird doch keine Verbindung zu https://hconnectweb.azurewebsites.net nötig sein?
Wie kann ich von der serverbasierten Steuerung auf die lokale Steuerung, sprich selbst verwaltetes Gateway wechseln? Die Richtung ist in den Anleitungen nicht beschrieben. Eine Übernahme der Einstellungen auf den Pi wäre toll.
Vielen Dank!
Jürgen
Serverbasiertes vs. lokales Gateway
Re: Serverbasiertes vs. lokales Gateway
Hallo Jürgen,
die Konfigurationsdaten liegen seit einiger Zeit immer auf dem Server. Bei Start des Gateways (entweder das in der Cloud, oder auch das lokale), bezieht dieses die Konfiguration vom Server und nutzt diese Konfiguration dann lokal. Die Verwaltung der Konfiguration kann also immer auf dem Server genutzt werden. Nutzt man das lokale Gateway im eigenen Netzwerk, so wird eine geänderte Konfiguration per Push auf das Gateway übertragen und dann dort genutzt. So viel zur Konfiguration.
Ist das ganze mit lokaler Installation schneller? Eher nicht, denn das Gateway in der Cloud arbeitet selbst mit mittlerweile über 300 verbundenen VPN Clients immer noch wesentlich performanter als ein Raspberry Pi. Man spart netzwerktechnisch auch nicht sehr viel (nach meinen Messungen maximal 150ms), und das wiederum würde sich nicht merklich als schneller für den Benutzer bemerkbar machen.
Um von der VPN-Lösung auf die lokale Lösung umzusteigen musst du folgendes tun:
- Deinstalliere das VPN AddOn auf der CCU
- Startet die CCU neu
- Nun musst du mindestens 30 Minuten warten. Irgendwann in dieser Zeit erkennt der Server, dass dein Client nicht mehr verbunden ist und verliert die Information, dass dieser Client ein VPN Client ist
- In dieser Zeit kannst du z.B. die lokale Installation auf einem Pi vorbereiten, aber noch nicht starten (du würdest immer wieder die Meldung erhalten, dass dieser Client über einen VPN Router verbunden ist)
- Nach den 30 Minuten startest du das lokale Gateway
Zurück zur VPN Lösung geht es so ähnlich:
- Lokales Gateway beenden
- 30 Minuten warten
- CCU VPN AddOn installieren
- CCU neu starten
- fertig
die Konfigurationsdaten liegen seit einiger Zeit immer auf dem Server. Bei Start des Gateways (entweder das in der Cloud, oder auch das lokale), bezieht dieses die Konfiguration vom Server und nutzt diese Konfiguration dann lokal. Die Verwaltung der Konfiguration kann also immer auf dem Server genutzt werden. Nutzt man das lokale Gateway im eigenen Netzwerk, so wird eine geänderte Konfiguration per Push auf das Gateway übertragen und dann dort genutzt. So viel zur Konfiguration.
Ist das ganze mit lokaler Installation schneller? Eher nicht, denn das Gateway in der Cloud arbeitet selbst mit mittlerweile über 300 verbundenen VPN Clients immer noch wesentlich performanter als ein Raspberry Pi. Man spart netzwerktechnisch auch nicht sehr viel (nach meinen Messungen maximal 150ms), und das wiederum würde sich nicht merklich als schneller für den Benutzer bemerkbar machen.
Um von der VPN-Lösung auf die lokale Lösung umzusteigen musst du folgendes tun:
- Deinstalliere das VPN AddOn auf der CCU
- Startet die CCU neu
- Nun musst du mindestens 30 Minuten warten. Irgendwann in dieser Zeit erkennt der Server, dass dein Client nicht mehr verbunden ist und verliert die Information, dass dieser Client ein VPN Client ist
- In dieser Zeit kannst du z.B. die lokale Installation auf einem Pi vorbereiten, aber noch nicht starten (du würdest immer wieder die Meldung erhalten, dass dieser Client über einen VPN Router verbunden ist)
- Nach den 30 Minuten startest du das lokale Gateway
Zurück zur VPN Lösung geht es so ähnlich:
- Lokales Gateway beenden
- 30 Minuten warten
- CCU VPN AddOn installieren
- CCU neu starten
- fertig
Re: Serverbasiertes vs. lokales Gateway
Danke für die ausführliche Erklärung!Kasimir hat geschrieben: ↑23 Jul 2017, 18:31Hallo Jürgen,
die Konfigurationsdaten liegen seit einiger Zeit immer auf dem Server. Bei Start des Gateways (entweder das in der Cloud, oder auch das lokale), bezieht dieses die Konfiguration vom Server und nutzt diese Konfiguration dann lokal. Die Verwaltung der Konfiguration kann also immer auf dem Server genutzt werden. Nutzt man das lokale Gateway im eigenen Netzwerk, so wird eine geänderte Konfiguration per Push auf das Gateway übertragen und dann dort genutzt. So viel zur Konfiguration.
Nach deinen Informationen macht es dann eigentlich keinen Sinn einer lokalen Installation. Es ist ja in jedem Fall eine Verbindung zu deinem Server nötig. Und dessen Verfügbarkeit soll ja besser werden
Danke! Jürgen
Re: Serverbasiertes vs. lokales Gateway
Guten Morgen,
während der letzten Tage hatte ich die das VPN AddOn installiert. Nun möchte ich gerne auf eine Raspberry Lösung schwenken.
Dabei bin ich wie folgt vorgegangen:
- Deinstalliere das VPN AddOn auf der CCU
- Startet die CCU neu
- Nun musst du mindestens 30 Minuten warten. Irgendwann in dieser Zeit erkennt der Server, dass dein Client nicht mehr verbunden ist und verliert die Information, dass dieser Client ein VPN Client ist
Gestern abend gegen 19:00 Uhr habe ich das VPN AddOn auf der CCU deinstalliert und die CCU neu gestartet.
Wenn ich mich nun auf "https://hconnectweb.azurewebsites.net/" schaue, wird mein Status noch immer als grün bzw. online angezeigt.
Gateway: Online (grün)
VPN: verbunden (grün)
HM: Zugriffsfehler (rot)
Auch heute morgen, gute 14 Stunden nach Deinstallation des AddOn's ist Gateway und VPN grün.
Was kann ich machen, bzw. ist das so korrekt ?
Danke und Grüße
Bibersen
während der letzten Tage hatte ich die das VPN AddOn installiert. Nun möchte ich gerne auf eine Raspberry Lösung schwenken.
Dabei bin ich wie folgt vorgegangen:
- Deinstalliere das VPN AddOn auf der CCU
- Startet die CCU neu
- Nun musst du mindestens 30 Minuten warten. Irgendwann in dieser Zeit erkennt der Server, dass dein Client nicht mehr verbunden ist und verliert die Information, dass dieser Client ein VPN Client ist
Gestern abend gegen 19:00 Uhr habe ich das VPN AddOn auf der CCU deinstalliert und die CCU neu gestartet.
Wenn ich mich nun auf "https://hconnectweb.azurewebsites.net/" schaue, wird mein Status noch immer als grün bzw. online angezeigt.
Gateway: Online (grün)
VPN: verbunden (grün)
HM: Zugriffsfehler (rot)
Auch heute morgen, gute 14 Stunden nach Deinstallation des AddOn's ist Gateway und VPN grün.
Was kann ich machen, bzw. ist das so korrekt ?
Danke und Grüße
Bibersen
Re: Serverbasiertes vs. lokales Gateway
Guten Morgen,
der Server hat gestern im Laufe des Tages den VPN connect verloren und ich konnte mein Raspberry Gateway starten. Soweit ich das beurteilen kann läuft es bisher ohne Probleme, bin begeistert.
Danke und Grüße
Bibersen
der Server hat gestern im Laufe des Tages den VPN connect verloren und ich konnte mein Raspberry Gateway starten. Soweit ich das beurteilen kann läuft es bisher ohne Probleme, bin begeistert.
Danke und Grüße
Bibersen
Re: Serverbasiertes vs. lokales Gateway
Hallo,
besten Dank für Dein Engagement und die super Software !!!
Nochmal zum Verständnis zu der lokalen Installation ... ich habe gelesen, dass die Konfigurationsdaten in jedem Fall auf dem Cloud-Server abgelegt werden, allerdings keine VPN Verbindung mehr zwischen CCU2 und der Cloud aufgebaut wird. Bedeutet diese Konfiguration, dass im Extremfall ausgeschlossen ist, dass z.B. jemand mein Passwort bei HConnect knackt und sich von dort Zugang auf die HM Geräte verschafft? Bzw. (und bitte nicht falsch verstehen!!!) wird dadurch ausgeschlossen, dass jemand die Server vom HConnect hackt und von dort aus Unfug veranstalten kann?
Ergänzend, verbindet sich Alexa bei einer lokalen Installation dann direkt mit dem Rasperry PI? Wie erfolgt diese Verbindung dann?
Viele Grüße und Danke für Eure Erläuterungen.
Alex
besten Dank für Dein Engagement und die super Software !!!
Nochmal zum Verständnis zu der lokalen Installation ... ich habe gelesen, dass die Konfigurationsdaten in jedem Fall auf dem Cloud-Server abgelegt werden, allerdings keine VPN Verbindung mehr zwischen CCU2 und der Cloud aufgebaut wird. Bedeutet diese Konfiguration, dass im Extremfall ausgeschlossen ist, dass z.B. jemand mein Passwort bei HConnect knackt und sich von dort Zugang auf die HM Geräte verschafft? Bzw. (und bitte nicht falsch verstehen!!!) wird dadurch ausgeschlossen, dass jemand die Server vom HConnect hackt und von dort aus Unfug veranstalten kann?
Ergänzend, verbindet sich Alexa bei einer lokalen Installation dann direkt mit dem Rasperry PI? Wie erfolgt diese Verbindung dann?
Viele Grüße und Danke für Eure Erläuterungen.
Alex
Re: Serverbasiertes vs. lokales Gateway
HConnect besteht aus den folgenden Komponenten:
- HConnect WebService (Zuständig für Konfiguration und "dispatcher" von Befehlen aus der "Alexa Cloud" (z.B. "Schalte ein/aus etc.")
- HConnect Gateway (Empfängt vom HConnect WebService Alexa Befehle und steuert daraufhin die angebundene Homematic-Zentrale)
(dies gibt es entweder lokal, oder auch in der Cloud)
- HConnect Vpn Server (dient lediglich dazu die eigene Homematic sicher an das HConnect Gateway in der Cloud anzubinden)
Angriffspunkte gibt es immer. Das fängt schon bei der Amazon Cloud an. Hackt sich dort jemand ein, könnte von dort aus ein gefälschtes "Schalte ein/aus" gesendet werden, was dann (vorausgesetzt die ganzen Schlüssel, Kennwörter und Tokens können ausgelesen werden) natürlich auch passiert.
Der Angriffspunkt beim Gateway in der Cloud könnte das Gateway in der Cloud oder der VPN Server sein. Ein Hacker könnte hier Vollzugriff auf die CCU bekommen.
Ist das Gateway zu Haus ist der Angriffspunkt der Dispatcher (also HConnect WebServer). Hier bekommt man zwar keinen Vollzugriff auf die CCU, aber auf alle Befehle die man mit Alexa senden kann.
Zur Beruhigung kann ich aber sagen, dass all diese Server extem abgesichert sind. Insgesamt sind in diesem System 4 Serverinstanzen verteilt. Um etwas anzurichten müsste man mindestens 2 davon kompromitieren. Ein System allein reicht da nicht. Die Systeme sind alle so eingerichtet, dass Administrative Zugriffe nur per 2FA möglich sind. Zusätzlich gibt es kleine "Gemeinheiten" auf den Servern welche sofort Alarm schlagen wenn administrative Vorgänge ausgeführt werden, oder bestimmte Daten abgerufen werden und diese Vorgänge nicht vorher über ein Verfahren (welches ich hier natürlich nicht weiter erklären kann) angemeldet wurden. In einem solchen Fall bekomme ich das definitv mit (ja, auch wenn ich schlafe), aber dann haben sich die Dienste wahrscheinlich eh schon selbst abgeschaltet.
Soweit erst einmal die Infos dazu...
LG
Carsten Deike
- HConnect WebService (Zuständig für Konfiguration und "dispatcher" von Befehlen aus der "Alexa Cloud" (z.B. "Schalte ein/aus etc.")
- HConnect Gateway (Empfängt vom HConnect WebService Alexa Befehle und steuert daraufhin die angebundene Homematic-Zentrale)
(dies gibt es entweder lokal, oder auch in der Cloud)
- HConnect Vpn Server (dient lediglich dazu die eigene Homematic sicher an das HConnect Gateway in der Cloud anzubinden)
Angriffspunkte gibt es immer. Das fängt schon bei der Amazon Cloud an. Hackt sich dort jemand ein, könnte von dort aus ein gefälschtes "Schalte ein/aus" gesendet werden, was dann (vorausgesetzt die ganzen Schlüssel, Kennwörter und Tokens können ausgelesen werden) natürlich auch passiert.
Der Angriffspunkt beim Gateway in der Cloud könnte das Gateway in der Cloud oder der VPN Server sein. Ein Hacker könnte hier Vollzugriff auf die CCU bekommen.
Ist das Gateway zu Haus ist der Angriffspunkt der Dispatcher (also HConnect WebServer). Hier bekommt man zwar keinen Vollzugriff auf die CCU, aber auf alle Befehle die man mit Alexa senden kann.
Zur Beruhigung kann ich aber sagen, dass all diese Server extem abgesichert sind. Insgesamt sind in diesem System 4 Serverinstanzen verteilt. Um etwas anzurichten müsste man mindestens 2 davon kompromitieren. Ein System allein reicht da nicht. Die Systeme sind alle so eingerichtet, dass Administrative Zugriffe nur per 2FA möglich sind. Zusätzlich gibt es kleine "Gemeinheiten" auf den Servern welche sofort Alarm schlagen wenn administrative Vorgänge ausgeführt werden, oder bestimmte Daten abgerufen werden und diese Vorgänge nicht vorher über ein Verfahren (welches ich hier natürlich nicht weiter erklären kann) angemeldet wurden. In einem solchen Fall bekomme ich das definitv mit (ja, auch wenn ich schlafe), aber dann haben sich die Dienste wahrscheinlich eh schon selbst abgeschaltet.
Soweit erst einmal die Infos dazu...
LG
Carsten Deike
Re: Serverbasiertes vs. lokales Gateway
Hallo Carsten,
besten Dank für Deine ausführlichen Erläuterungen, sehr interessant die Architektur zu verstehen.
Wenn man nun das Gateway lokal installiert bleibt als Cloud Dienst bzw. Angriffspunkt wie Du schreibst der HConnect WebServer. Mir geht es darum, dass im Extremfall einige wenige Geräte von irgendwelchen Bösewichten nicht angesteuert werden können. Ich würde also in dem lokalen Gateway so konfigurieren, dass diese Geräte nicht für Alexa bereitgestellt werden, damit sollte das Risiko doch unterbunden sein, oder? Eine letzte Frage noch, die Verbindung vom lokalen Gateway zum HConnect WebServer, wie erfolgt diese? Wird hierfür eine VPN Verbindung aufgebaut?
Nochmals Danke + viele Grüße
Alex
besten Dank für Deine ausführlichen Erläuterungen, sehr interessant die Architektur zu verstehen.
Wenn man nun das Gateway lokal installiert bleibt als Cloud Dienst bzw. Angriffspunkt wie Du schreibst der HConnect WebServer. Mir geht es darum, dass im Extremfall einige wenige Geräte von irgendwelchen Bösewichten nicht angesteuert werden können. Ich würde also in dem lokalen Gateway so konfigurieren, dass diese Geräte nicht für Alexa bereitgestellt werden, damit sollte das Risiko doch unterbunden sein, oder? Eine letzte Frage noch, die Verbindung vom lokalen Gateway zum HConnect WebServer, wie erfolgt diese? Wird hierfür eine VPN Verbindung aufgebaut?
Nochmals Danke + viele Grüße
Alex
Re: Serverbasiertes vs. lokales Gateway
Hallo Carsten,
wünsche Dir einen schönen dritten Advent!
Sei bitte so nett und gib mir noch eine Antwort auf meine Frage, wäre sehr nett von Dir!
Viele Grüße
Alex
wünsche Dir einen schönen dritten Advent!
Sei bitte so nett und gib mir noch eine Antwort auf meine Frage, wäre sehr nett von Dir!
Viele Grüße
Alex
Re: Serverbasiertes vs. lokales Gateway
Hallo AlexK,
die Verbindung zwischen lokalem Gateway und HConnect Service ist natürlich verschlüsselt.
Dein lokales Gateway baut dazu zunächst eine Verbindung zum HConnect Service über https auf und handelt auf diesem sicheren Kanal zunächst ein paar Verschlüsselungsparameter aus. Danach erfolgt die Kommunikation zwischen den beiden Services stets verschlüsselt mit diesen Parametern. Hierzu gibt es ein Verfahren, welches hier http://structuremap.net/hybrid-encryption-rsaaes/ beschrieben ist.
Nach ca. 20 Minuten geht das gleiche Spielchen wieder von vorn los. Die Verschlüsselungsparameter werden erneut vom lokalen Gateway aus initiiert erzeugt.
die Verbindung zwischen lokalem Gateway und HConnect Service ist natürlich verschlüsselt.
Dein lokales Gateway baut dazu zunächst eine Verbindung zum HConnect Service über https auf und handelt auf diesem sicheren Kanal zunächst ein paar Verschlüsselungsparameter aus. Danach erfolgt die Kommunikation zwischen den beiden Services stets verschlüsselt mit diesen Parametern. Hierzu gibt es ein Verfahren, welches hier http://structuremap.net/hybrid-encryption-rsaaes/ beschrieben ist.
Nach ca. 20 Minuten geht das gleiche Spielchen wieder von vorn los. Die Verschlüsselungsparameter werden erneut vom lokalen Gateway aus initiiert erzeugt.
Wer ist online?
Mitglieder in diesem Forum: 0 Mitglieder und 0 Gäste