Neuer smarthomeNG -Treiber: jetzt Standard in v3.3

[wvhn]

In der aktuellen Version v3.2 ist ein zusätzlicher Backend-Treiber für smarthomeNG. Er soll die Konflikte lösen, die es im Betrieb hinter einem Reverse Proxy immer wieder zwischen dem externen Zugriff via Domainnamen und dem internen Zugriff via IP-Adresse gab, weil sich beides nicht zusammen konfigurieren ließ.

Neu ist, dass IP-Adresse / Hostname und die Websocket-Ports für shNG immer angegeben werden müssen. Zudem muss der Hostname des smartVISU-Servers in einem neuen Feld eingetragen werden, sofern der Hostname für den Aufruf der Visu verwendet wird.

Der Treiber, der im Konfigurationsmenü als „smarthomeNG new“ angezeigt wird, verbindet sich dann wie folgt mit dem shNG Websocket:

• Ruft der Benutzer die Visu mittels IPv4-Adresse auf (z. B. http://192.168.2.10/smartVISU), dann verwendet der Treiber die Adresse und die Ports aus der Konfiguration.
• Wird die Visu per Hostname aufgerufen (z.B. http://smarthome.local/smartVISU), dann prüft der Treiber, ob der verwendete Hostname (im Beispiel „smarthome.local“) der konfigurierte SV-Hostname ist und verwendet in diesem Fall wieder die konfigurierte Adresse und die Ports.
• entspricht der Hostname im Seitenaufruf nicht dem konfigurierten SV-Hostnamen, dann geht der Treiber von einer externen Verbindung aus und spricht den Websocket über den Hostnamen, Port 80/443 und das Protokoll ws: / wss: an.

Der Treiber wird zusätzlich zum bisherigen Treiber ausgeliefert. Den bisherigen Treiber werde ich dann in der übernächsten Version auf deprecated setzen, wenn mit dem neuen alles OK ist.

Wichtig: beide Treiberversionen unterstützen in gleicher Weise die Verbindung mit den beiden shNG-Ports für verschlüsselte und unverschlüsselte Websocketvberbindungen.

Gruß
Wolfram

[wvhn]

in smartVISU v3.3 ist der neue Treiber zum Standard geworden und der bisherige Treiber wurde in den Ordner ./driver/deprecated verschoben.

Im develop branch ist seit heute eine erweiterte Version, die eine alternative Adresse für den Websocket verwenden kann. Sinnvoll ist dies, wenn man eine verschlüsselte Verbindung zum Websocket herstellen, aber kein selbstsigniertes Zertifikat mit der IP-Adresse einsetzen will. In diesem Fall braucht man einen Domain-Namen, auf den ein Zertifikat ausgestellt ist und unter dem sowohl die Visu, als auch der Websocket erreichbar sind.

Um dies zu nutzen, muss man in der ./config.ini manuell einen Eintrag für die alternative Adresse anlegen, z.B.:

driver_address2 = "visu.meinedomain.com"

Man ruft dann die Visu über "https://visu.meinedomain.com/smartVISU" auf.

Da dies ein eher spezieller Fall ist, wird es bei der manuellen Konfiguration bleiben, d.h. es wird keine weitere Option auf der Config-Seite geben.

Gruß
Wolfram

[henfri]

Hallo Wolfram,

kannst du dazu noch ein bisschen mehr sagen?
Gibt es ein Beispiel/eine Anleitung, wie die SV von Außen ohne VPN erreichbar gemacht werden kann?

Ich vermute, das Folgende ist nötig:
- Ein Zertifikat für die Domain
- Dieses muss SmarthomeNG bekannt gemacht werden
- Dieses muss dem Reverse-Proxy bekannt gemacht werden
- Der Externe Port, den ich im Browser angebe muss 443 sein, da die SV diesen fest verdrahtet hat. Dieser muss also im Router an den (beliebigen) Port des RP weitergeleitet werden.
- Im ReverseProxy muss (wie?) bekannt gemacht werden dass wss://meine.visu.de calls an sh-ng weitergegeben werden sollen und https://meine.visu.de calls auf die SV weitergegeben werden sollen.
- driver_Adress2 muss gesetzt sein.

Richtig?

Gruß,
Hendrik

[wvhn]

Hallo Hendrik,

da smartVISU auf dem Endgerät (Client) läuft, braucht dieses immer 2 Verbindungen:

• eine Verbindung zum Webserver für smartVISU - i.d.R. Apache2 oder nginx
• eine Verbindung zum Websocket von smarthomeNG

Hinzu kommt, dass moderne Browser kein "Downgrade" der Verbindung akzeptieren. Ruft man die Visu-Seiten beim Webserver mit https:// ab, dann darf die zugehörige Websocket-Verbindung nicht unverschlüsselt sein. Das heißt zumindest aus Sicht des Clients müssen beide Verbindungen verschlüsselt sein, wenn man aus dem Internet verschlüsselt auf seine Visu zugreifen will.

Dazu benötigt man ein Zertifikat für die Domain, das dem Reverse Proxy bekannt gemacht werden muss, denn er übernimmt die Rolle des Webservers für beide Verbindungen nach außen. Was dann hinter dem Reverse Proxy passiert, ist eine Frage von dessen Konfiguration. Das heißt der Reverse Proxy kann mit dem Webserver für smartVISU und mit dem Websocket-Server von shNG auch unverschlüsselt kommunizieren.

Will man auch hausintern hinter dem Reverse Proxy eine verschlüsselte Kommunikation verwenden, benötigt man ein Zertifikat, das dem Websocket-Server von shNG bekannt gemacht werden muss. Dieses kann selbsterstellt sein, wie ich es hier im Forum schon einmal beschrieben habe. Nachteil eines selbsterstellten Zertifikats ist, dass man es jedem einzelnen Browser bekannt machen muss, dass nicht alle Browser dies für Websockets akzeptieren und das es immer wieder erneuert werden muss. Die bessere Lösung ist daher die Verwendung einer Domain, für die ein Zertifikat mit offizieller Zertifizierung erstellt ist. Dann muss man den Websocket-Server auch intern unter dieser Domain verfügbar machen und statt der IP-Adresse die Domain im Treiber angeben. Dafür dient der neue Parameter driver_address2 in der config.ini.

Der Externe Port, den ich im Browser angebe muss 443 sein, da die SV diesen fest verdrahtet hat. Dieser muss also im Router an den (beliebigen) Port des RP weitergeleitet werden.

Der Port für https:// ist defaultmäßig 443. In smartVISU ist nichts fest verdrahtet. Du kannst im Aufruf der smartVISU (https://...) auch einen anderen Port verwenden. Für den Websocket wird dann derselbe Port verwendet, jedoch mit Protokoll wss://. Der Reverse Proxy muss beides dann richtig weiter leiten.

Im ReverseProxy muss (wie?) bekannt gemacht werden dass wss://meine.visu.de calls an sh-ng weitergegeben werden sollen und https://meine.visu.de calls auf die SV weitergegeben werden sollen.

Richtig. In der Regel wird die Visu eher unter https://meine.Domain.de/smartVISU erreichbar sein. In der Konfigurationsdatei für nginx kann dann für Root und für jedes Unterverzeichnis der Domain angegeben werden, wohin und mit welchem Protokoll weitergeleitet werden soll. Dazu gibt es im Forum mehrere Threads, z.B. diesen.

driver_Adress2 muss gesetzt sein.

Nein. Siehe oben

Gruß
Wolfram