Reverse Proxy - Kein Zugriff auf Websocket

[Msinn]

Cannon

?

Meinst Du wss und ws?

Das hat wolfram gerade im develop implementiert

[Cannon]

Meinst Du wss und ws?

Das hat wolfram gerade im develop implementiert

Das klingt gut. Ich denke, ich meine das. Bin mir aber nicht sicher. In der VISU stelle ich ja den Host und den Port ein. Und das meine ich.

[wvhn]

Für den Websocket ist das seit heute realsiert und im develop branch verfügbar. Siehe hier. Damit sollte es möglich sein, die Weiterleitungen im nginx sauber zu konfigurieren. Was allerdings noch fehlt, ist eine IP und ein Port für den Fall, dass ein Reverse Proxy genutzt wird (IP und Port bleiben in der smartVISU-Konfiguration leer) und der interne Zugriff direkt laufen soll. Da muss ich mir noch was einfallen lassen. Wer heute die IP und den Port nicht selbst fest in den Treiber integrieren will, muss seinen Reverse Proxy so konfigurieren, dass er auch innerhalb des Heimnetzes ansprechbar ist.

Bisher hat sich jeder, den ich gebeten hatte, seine Schritte zum erfolgreichen Aufsetzen eines Reverse Proxy mal sauber zu dokumentieren, ganz schnell wieder vom Acker gemacht. Bei dieser Form von Mitarbeit lasse ich die Finger von nginx und teste die Erweiterungen der Visu eben mit Apache2.

Gruß
Wolfram

[element]

Entschuldigt bitte das ich mich jetzt erst wieder melde, hatte ne stressige Woche. Seit dem Wochenende hab ich eure Tips ausprobiert und das develop installiert

Die Änderung am io-Treiber bewirkt, dass der Websocket im internen Netz gefunden wird. Das fehlt bisher noch, wenn man für den Reverse Proxy die Adresse und den Port in der Konfiguration weglässt. Funktioniert denn dieser Zugang von innerhalb des LANs über HTTP wenigstens?

Welche shNG-Version verwendest Du und welche smartVISU-Version?
Mit aktuellem shNG solltest Du das Websocket-Modul verwenden - nicht das veraltete Plugin. Hast Du Deine Let'sencrypt Schlüssel- und Zertifikatsdateien im Ordner /usr/local/smarthome/etc abgelegt und dem Websocket-Modul die Namen mitgeteilt?

Die Weiterleitung der Websocket-Anfrage auf den Port 2424 kann so nicht gehen, weil das der unverschlüsselte Port des Websocket-Moduls ist. Entweder muss der nginx dazu gebracht werden, innerhalb des LANs über HTTP zu gehen (aus meiner Sicht die Vorzugslösung), oder die Weiterleitung muss auf denTLS-Port gehen.

Gruß
Wolfram

smarthome version ist "1.8.2.master"
smartvisu version war zum Zeitpunkt meine Anfrage "3.1"
smartvisu Version jetzt ist das aktuelle develop "3.1a"
auf die develop Version verlinkt der reverse proxy
Ich habe wieder

alert(protocol + io.address + ':' + io.port);

eingefügt um zu sehen wohin der Treiber weiterleitet
unter http - ws://<smartvisu-ipv4>:2424 - Verbindung klappt
unter https - wss://<smartvisu-ipv4>:2425 - Verbindung klappt nicht
in smarthome erhalte ich den Fehler:

2021-07-26 13:03:47 ERROR asyncio SSL error in data received
protocol: <asyncio.sslproto.SSLProtocol object at 0x7fef753a1b00>
transport: <_SelectorSocketTransport closing fd=40 read=idle write=<idle, bufsize=0>>
> Traceback (most recent call last):
> File "/usr/lib/python3.7/asyncio/sslproto.py", line 526, in data_received
> ssldata, appdata = self._sslpipe.feed_ssldata(data)
> File "/usr/lib/python3.7/asyncio/sslproto.py", line 189, in feed_ssldata
> self._sslobj.do_handshake()
> File "/usr/lib/python3.7/ssl.py", line 763, in do_handshake
> self._sslobj.do_handshake()
> ssl.SSLError: [SSL: SSLV3_ALERT_CERTIFICATE_UNKNOWN] sslv3 alert certificate unknown (_ssl.c:1056)

Ich denke mal das die Zertifikate letsencrypt falsch sind.
eingefügt habe ich sie insmarthome unter etc/ und umbenannt
genommen habe ich die Zertifikate aus
/etc/letsencrypt/live/<mydomain>.<myds>.<me>/
@cert.pem und @privkey.pem
und beim zweiten Versuch
/etc/letsencrypt/archive/<mydomain>.<myds>.<me>/
cert1.pem und privkey.pem
bekomme mit beiden nur meine smartvisu Seite angezeigt ohne Verbindung zu smarthome
und mit den Zertifikaten von " /etc/letsencrypt/archive/<mydomain>.<myds>.<me>/ "
kommt kein Fehler im log von smarthome
das ganze klappt aus dem Internet genauso schlecht wie im lan über ssl
Nachtrag:
Ich habe das log modules.Websocket auf info gestellt - es kommt über port 2425 nichts an in smarthome

[wvhn]

Die Zertifikate müssen auf die IP-Adresse von shNG ausgestellt sein. Die letsencrypt Zertifikate für Deine externe Domain nutzen da nichts.

Hast Du den Link zur erprobten Vorgehensweise in meinem vorigen Post gesehen?

Gruß
Wolfram

[element]

Mist,.da hab ich was falsch verstanden, gucke ich mir an. Danke schonmal
30.07.
hab heute alles nach deiner Anleitung eingerichtet, auf meinem smarthome- Server läuft apache
Ich kann jetzt im lan über https auf smatvisu mit Steuerung über wss zugreifen
leider funktioniert es immer noch nicht über wan - internet
die smartvisu Seite wird angezeigt, Daten kommen nicht, cache gelöscht und Browser Neustart keine Besserung
Es klappt ebenfalls im lan über den reverse proxy über ipv4 und ipv6
Von außen erreiche ich meinen Router nut noch über IPV6

[element]

Es klappt immer noch nicht. Wenn ich das mit dem websocket richtig verstanden habe verbindet der sich direkt mit dem Client, oder? Wenn ich in smartvisu eine ipv4 Adresse angebe und mich von außen über ipv6 verbinde, dann kann der websocket mich doch gar nicht finden.
Ist das richtig?
Ich müsste demzufolge im smartvisu die ipv6 Adresse einstellen.
Das wiederum hätte zur Folge daß ich um erreichbar zu bleiben ich alles auf ipv6 umstellen müsste.
Bevor ich das in Angriff nehmen und ich falsch liege könnte mir das bitte jemand bestätigen?

[wvhn]

Von außen kommst Du doch sicherlich über eine DynDNS rein und nutzt dafür Deine Letsencrypt-Zertifikate. Der Browser (Client) kennt dann nur die DynDNS und fordert auf dieser per http(s) die statischen Webseiteninhalte vom smartVISU-Webserver an, sowie per ws(s) die dynamischen Inhalte vom Websocket-Modul von shNG. Der Reverse Proxy muss das entsprechend dem Verbindungstyp mit dem richtigen Protokoll durchreichen. Dazu müssen die Angaben für IP-Adresse und Port in der smartVISU-Config leer bleiben und Du stellst IP und Port jeweils pro Verbindung im Reverse Proxy ein. Ich vermute, dass man dem Reverse Proxy zusätzlich die „internen“ Zertifikate des Websockets bekannt machen muss, damit er an die wss-Daten heran kommt. Da die interne Kommunikation per https/wss noch weitere Nachteile hat, würde ich empfehlen, diese unverschlüsselt laufen zu lassen und den Revers Proxy die Umsetzung auf verschlüsselte Kommunikation machen zulassen.

Gruß
Wolfram

[element]

Ich habe zur Zeit die develop Version von smartvisu installiert die ws und wss erlaubt Wenn ich dort das Feld " Reverse Proxxy " aktiviere löscht smartvisu die IP und die Ports. Das müsste doch die richtige Ausgangslage sein.

[wvhn]

Ja. Für den externen Zugriff. Der interne klappt dann nicht mehr, es sei denn man modifiziert den Treiber so, dass er bei einer bestimmten Client-IP die IP und den Port vom shNG-Websocket verwendet.
Das will ich noch ändern. Voraussichtlich werde ich einfach dann die interne Verbindung aktivieren, wenn der Client im selben IPv4 Bereich ist, wie shNG.

[element]

Es klappt, ich habe endlich wieder Zugriff auf die visu mit Weiterleitung des websockets zu smarthomeng und freue mich wie Bolle.
Danke für die Hilfe und die Geduld.
Woran es schlussendlich gelegen hat, das der websocket nicht weitergeleitet wurde war eine Änderung in der nginx config
/etc/nginx/conf.d/<mydomain>.<myds>.<me>.conf

lt Anleitung

# Weiterleitung zu SmartHomeNG (Websocket Schnittstelle) mit Basic Auth
location / {
if ($http_upgrade != websocket) {
return 404;
proxy_pass http://10.0.10.9:2424;
include /etc/nginx/headers.conf;
}

und so funktionierts

# Weiterleitung zu SmartHomeNG (Websocket Schnittstelle) mit Basic Auth
location / {
auth_basic "Restricted Area: smartvisu";
auth_basic_user_file /etc/nginx/.smartvisu;
proxy_pass http://10.0.10.9:2424;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
}

in smartvisu muss der reverse Proxy eingeschaltet sein und somit ist keine Eingabe von host und port möglich.
Die Visu ist nur noch über den reverse Proxy erreichbar, vom lan und vom wan