Zugriff von extern / WSS

[sepplo815]

Hi,

schließe mich der Bitte von luxi an.
Habe auch den Pi Reverse Proxy (Apache2) für die Alexa Integration von jonefe am Laufen.
Wäre jemand bitte so lieb und könnte eine „kurze“ Anleitung zur Ergänzung der Apache2 Konfiguration bzw. der EDOMI Änderungen zusammenstellen. Quasi als Ergänzung zu dieser Anleitung von jonefe hier #1:
https://knx-user-forum.de/forum/proj...6-und-19000647

Danke und Gruß
Seppl

[EinAnfaenger]

das wäre dann hier in der main.js, oder?

function class_websocket() {
var that=this;

this.open=function(serverIp,serverPort) {
try {
socket=new WebSocket('[B]ws[/B]://'+serverIp+':'+serverPort);

Ich spiele auch gerade mit Edomi/Zugriff via Reverse Proxy rum. Folgende Änderung in der main.js sorgt dafür, das die Visus sowohl via HTTP als auch via HTTPS erreichbar gemacht werden können. Wenn der Zugriff via HTTP erfolgt wird der WebSocket ganz normal mit ws:// geöffnet, beim Zugriff via SSL dann eben mit wss://

Getestet mit Chrome (mit SSL über einen nginx als Reverse Proxy auf einer anderen Machine), Safari kann ich mangels Safari nicht testen
Vielleicht mag das noch jemand testen und wenns auch da klappt kann gaert das ja vielleicht beim nächsten Update berücksichtigen?

function class_websocket() {
        var that=this;

        this.open=function(serverIp,serverPort) {
                try {
                        if (location.protocol == 'https:') {
                                socket=new WebSocket('wss://'+serverIp+':'+serverPort);
                        } else {
                                socket=new WebSocket('ws://'+serverIp+':'+serverPort);
                        }

[gaert]

Kann ich machen. Allerdings ist es dann wichtig zu wissen (für den Nutzer), dass der Aufruf per HTTPS nur mit Hilfe eines Reverse-Proxys funktionieren wird (nur Apache auf HTTPS zu konfigurieren reicht natürlich nicht aus).

[starwarsfan]

Macht es nicht Sinn, das via Konfiguration aktivieren zu können? Es gibt sicher nicht wenige, die https ohne Proxy verwenden...

[coliflower]

Eine Umstellung auf HTTPS wäre für einige sicher sehr positiv …
Heute ist so ziemlich alles via https zuhause erreichbar (Fire-Wall, Switch, Nas, …)

[gaert]

starwarsfan
Schon, aber ohne Proxy (o.d.G.) wird https nicht funktionieren... Serverseitig kann ein wss-Socket nicht verarbeitet werden, da ich dieses Protokoll nicht implementiert habe.

[EinAnfaenger]

Der Einwand von Christian ist natürlich berechtigt. Wie groß der Aufwand ist, das über die Konfigurationsdatei zu steuern kann ich nicht beurteilen, es geht dabei ja um eine der JS-Dateien. Da Edomi von Haus aber sowieso ohne SSL ausgeliefert wird sollte das aber auch erstmal kein Problem sein. Ein Hinweis in der Installationsanleitung wäre wohl trotzdem angebracht (und dazu doch ein guter Test dafür, wer die überhaupt liest ).

Den Edomi-Apache einfach auf SSL umzustellen und von außen darauf zuzugreifen halte ich aber für keine gute Idee. Das Linux ist alt, die enthalten Software inkl. des Apache ist alt (also alles außer Edomi ). Alles was von außen zureifbar ist, sollte aktualisierbar sein und aktuelle Versionen verwenden. Deswegen lasse ich die Edomi-Maschine so wie sie ist und bastele auch nicht dran rum. Den Zugriff von außen lasse ich daher über einen Proxy laufen den ich auf dem aktuellen Stand halten kann und der sich um die Verschlüsselung und die Authentifizierung kümmert (in meinem Fall mittels Client-Zertifikat). Damit der Hardwareaufwand nicht zu groß wird, läuft sowohl Edomi als auch der Proxy jeweils in einer eigenen VM auf einer APU2C4.

[simonlaessig]

Den Zugriff von außen lasse ich daher über einen Proxy laufen den ich auf dem aktuellen Stand halten kann und der sich um die Verschlüsselung und die Authentifizierung kümmert (in meinem Fall mittels Client-Zertifikat). Damit der Hardwareaufwand nicht zu groß wird, läuft sowohl Edomi als auch der Proxy jeweils in einer eigenen VM auf einer APU2C4.

Würdest du dir die mühe machen und für Nginx (oder apache?!) die reversed Proxy Anleitung schreiben? Deine Websocket änderung an Edomi hab ich durchgeführt.

[EinAnfaenger]

Zwar keine Anleitung, aber hier mal meine nginx Konfiguration (Apache als Reverse Proxy habe ich nie gemacht):

map $http_upgrade $connection_upgrade {
    default upgrade;
    '' close;
}

upstream websocket {
    server            edomi.server.name:8080;    # <- Edomi Rechner-Name bzw. -IP
}

# Edomi Server
server {
    listen            a.b.c.d:443;        # <- Edomi IP
    server_name        proxy.server.name;    # <- Name des Reverse Proxys (muss kein "echter" DNS-Name sein)

    ssl            on;
    ssl_certificate        /etc/nginx/ssl/crt.pem;
    ssl_certificate_key    /etc/nginx/ssl/key.pem;
#    ssl_client_certificate    /etc/nginx/ssl/ca.crt.pem;
#    ssl_verify_client    on;

    location / {
                proxy_pass http://edomi.server.name/;
    }

    error_log        /var/log/nginx/edomi-error.log;
    access_log        /var/log/nginx/edomi-access.log;
}

# Websocket
server {
    listen            a.b.c.d:8080;        # <- IP des Reverse Proxys

    ssl            on;
    ssl_certificate        /etc/nginx/ssl/crt.pem;
    ssl_certificate_key    /etc/nginx/ssl/key.pem;

    location / {
                proxy_pass http://websocket;
                proxy_http_version 1.1;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection "upgrade";
    }
    error_log        /var/log/nginx/ws-error.log;
    access_log        /var/log/nginx/ws-access.log;
}

Die passenden Zertifkate muss man sich natürlich auch noch erstellen (lassen).

Die beiden auskommentierten Zeilen ssl_client_certificate und ssl_verify_client sind für die Authentifizierung via Client-Zertifikat. wer das nicht möchte kann die auch auskommentiert lassen bzw. löschen.

[gaert]

Ich sehe ja nach wie vor überhaupt keinen Bedarf für SSL/HTTPS... Im Haus (bzw. LAN/WLAN) dürfte/sollte sich kein Man-in-the-middle rumtreiben - sonst hat man irgendwas grundsätzliches falsch gemacht (Stichwort: Gast-WLAN, etc.). Und wer per Port-Forwarding auf sein "Heimnetz" zugreift, dem ist ohnehin nicht mehr zu helfen...

[simonlaessig]

Zwar keine Anleitung, aber hier mal meine nginx Konfiguration (Apache als Reverse Proxy habe ich nie gemacht):

Wenn man kaum Linux kentnisse hat bekommt man das einfach nicht hin, ich bin soweit das ich ubuntu mit nginx (und ajenti webinterface) installiert habe. Aber dann gehts nicht weiter, mit Copy Paste in die nginx.conf ist es wohl nicht getan. Über eine step by step Anleitung würden sich hier bestimmt mehrere freuen von mir aus auch ohne ssl, wenn man jeden befehl und alles googlen muss ist das einfach nicht schön

[EinAnfaenger]

Ich sehe ja nach wie vor überhaupt keinen Bedarf für SSL/HTTPS... Im Haus (bzw. LAN/WLAN) dürfte/sollte sich kein Man-in-the-middle rumtreiben - sonst hat man irgendwas grundsätzliches falsch gemacht (Stichwort: Gast-WLAN, etc.). Und wer per Port-Forwarding auf sein "Heimnetz" zugreift, dem ist ohnehin nicht mehr zu helfen...

Der SSL Kram ist auch explizit nicht für den Zugriff von "im Haus" gedacht sondern für den Zugriff von außen als Alternative zum VPN. Darum auch die Änderung an der main.js, damit eben beides geht. Wenn ich meinem LAN nicht mehr vertrauen kann ist wie Du sagst grundsätzlich was faul.

[EinAnfaenger]

Wenn man kaum Linux kentnisse hat bekommt man das einfach nicht hin, ich bin soweit das ich ubuntu mit nginx (und ajenti webinterface) installiert habe. Aber dann gehts nicht weiter, mit Copy Paste in die nginx.conf ist es wohl nicht getan. Über eine step by step Anleitung würden sich hier bestimmt mehrere freuen von mir aus auch ohne ssl, wenn man jeden befehl und alles googlen muss ist das einfach nicht schön

Ubuntu ist mir zu aufgebläht, ich nutze Debian
Ohne SSL macht das Ganze im Übrigen so gar keinen Sinn (außer zum Testen ob der Proxy funktioniert).

ajenti kenne ich nicht. Nimm die Kommandozeile
nginx sollte sich eigentlich auf allen Systemen ähnlich konfigurieren lassen. Die nginx.conf muss man i.d.R. nicht angriffeln.

Den Kram aus #24 in eine neue Datei /etc/nginx/sites-available/edomi kopieren und anpassen (IP-Adressen etc.).
In den Ordner /etc/nginx/sites-enabled wechseln, den Link default löschen und mit ln -s /etc/nginx/sites-available/edomi einen neuen Link auf die Edomi-Config erstellen.

Das sollte es auch schon gewesen sein. nginx (neu) starten und ausprobieren.

Die SSL Zertifikate kann man sich z.B. auch bei Let's encrypt erstellen lassen, aber das ist wieder ein anderes Thema...

[luxi]

Hallo, ich habe es jetzt auch geschafft meinen Reverse Proxy mit Apache wieder zum Laufen zu bekommen. Anbei eine Anleitung. Danke an alle Unterstützer!!!

[simonlaessig]

Habe es gerade eben auch hinbekommen mit Debian und Nginx. Dazu Debian 64 in der neusten Version auf z.B. einer VM ohne Webserver und Grafische Oberfläche installieren. Nun am Einfachsten weiter mit WinSCP oder mit Putty. IP Adresse einstellen. Nginx installieren. Dann wie in Post #28 eine neue Datei namens edomi in /etc/nginx/sites-available/ erstellen und den Inhalt einfügen:

ACHTUNG! SSL ist hier deaktiviert:

map $http_upgrade $connection_upgrade {
    default upgrade;
    '' close;
}

upstream websocket {
    server            a.b.c.d:8080;    # <- Edomi IP mit Websocket Port
}

# Edomi Server
server {
    listen            a.b.c.d:80;        # <- Reverse Proxy IP mit HTTP Port

#    ssl            on;
#    ssl_certificate        /etc/nginx/ssl/crt.pem;
#    ssl_certificate_key    /etc/nginx/ssl/key.pem;
#    ssl_client_certificate    /etc/nginx/ssl/ca.crt.pem;
#    ssl_verify_client    on;

    location / {
                proxy_pass http://a.b.c.d:80/;    # <- Edomi IP mit HTTP Port
    }

    error_log        /var/log/nginx/edomi-error.log;
    access_log        /var/log/nginx/edomi-access.log;
}


# Websocket
server {
    listen            a.b.c.d:8080;        # <- IP des Reverse Proxy mit Websocket Port


#    ssl            on;
#    ssl_certificate        /etc/nginx/ssl/crt.pem;
#    ssl_certificate_key    /etc/nginx/ssl/key.pem;

    location / {
                proxy_pass http://websocket;
                proxy_http_version 1.1;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection "upgrade";
    }
    error_log        /var/log/nginx/ws-error.log;
    access_log        /var/log/nginx/ws-access.log;
}

Dann in dem Ordner /etc/nginx/sites-enabled den link von default auf die neue Datei (edomi) ändern mit WinSCP oder per console default löschen und einen neuen Link erstellen (ln -s /etc/nginx/sites-available/edomi)

Neu starten und testen. Im Router dann Port 80 und 8080 zum Reverse Proxy freigeben (Achtung, wie gesagt kein SSL).

Danke an EinAnfaenger und alle anderen unterstützer. Nun schaue ich ob ich das mit SSL auch hinbekomme.