EDOMI über nginx-reverse proxy - mit Nginx Proxy Manager?

[ThorstenGehrig]

Hi
ich bin gerade am "basteln" meinen reverse-proxy umzustellen von Apache auf nginx. Dazu verwende den "Nginx Proxy Manager" (läuft im Docker).
Bisher habe ich alle meine reverse-proxies umgestellt - inkl. Zertifikatbasierender user-authentifizierung.
Funktioniert alles alles perfekt - bis auf den Websocket... Den habe ich noch immer über einen Apache-Reverseproxy am laufen.
Umstellung auf den nginx kriege ich aber nicht gebacken.
Hat schon jemand nginx über den proxy manager für EDOMI erfolgreich konfiguriert?

Gruß
Thorsten

[givemeone]

Was geht denn nicht?

hier habe ich etwas dazu geschrieben:
https://knx-user-forum.de/forum/proj...39#post1304239

[ThorstenGehrig]

>Was geht denn nicht?

naja - der websocket geht halt nicht ... :-)
Deinen Docker-Kommentar/nginx-config hab ich schon gelesen ... bringt mir aber nicht viel da der nginx-config-manager das so nicht zulässt.
Derzeit hab ich den 8080 noch über einen Apache-reverse-proxy am laufen - das Webinterface habe ich schon per nginx am laufen (mit https und client zur per zertifikat-basierender authentisierung).
Aus deiner Config hab ich auch mal die 5 sub-directories übernommen - scheint zu funktionieren.
Nur wie ich für / den websocket konfiguriert kriege ist mir nicht klar.
Der nginx-proxy-manager erlaubt ein "websocket support"-schalter - ist natürlich eingeschaltet.
Ich habe für / port 8080 eingeben (da läuft ja der WS)

Da ich den nginx-proxy-manager auf jedenfall verwenden möchte - da er mir viele andere websiten published - kämpfe ich hier dem dieser konfig... :-(

Gruß
Thorsten

[givemeone]

Ich kenne den proxy Manager nicht.
in meiner Config ist das = / das wichtige.
Warum nimmst du einen proxy überhaupt, wäre interessant um es zu verstehen.
Willst du Webseiten und websocket am selben Port nutzen, wie ich es möchte, oder soll der websocket bei dir auf 8080 bleiben?

Ohne Hintergrundinfo kann ich dir leider wenig weiter helfen.

[saegefisch]

Bei mir läuft folgendes schon sehr lange ganz wunderbar (ebenfalls mit CC-Zertifikaten) mit einem nginx-RevProxy in der DMZ:

[...]

#######
# MAP (für WebSocket erforderlich)
###
map $http_upgrade $connection_upgrade {
default upgrade;
'' close;
}


#######
# UPSTREAM
###
upstream websocket { server <IP edomi>:8080; }

[...]

#######
# HTTPS | edomi | nextcloud | ...
###
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;

server_name <subdomain>;

ssl_verify_client on; # on | off | optional | optional_no_ca
location / { proxy_pass http://<IP edomi>:80/; }

}

[...]

[eric4980]

>Was geht denn nicht?

naja - der websocket geht halt nicht ... :-)
Deinen Docker-Kommentar/nginx-config hab ich schon gelesen ... bringt mir aber nicht viel da der nginx-config-manager das so nicht zulässt.
Derzeit hab ich den 8080 noch über einen Apache-reverse-proxy am laufen - das Webinterface habe ich schon per nginx am laufen (mit https und client zur per zertifikat-basierender authentisierung).
Aus deiner Config hab ich auch mal die 5 sub-directories übernommen - scheint zu funktionieren.
Nur wie ich für / den websocket konfiguriert kriege ist mir nicht klar.
Der nginx-proxy-manager erlaubt ein "websocket support"-schalter - ist natürlich eingeschaltet.
Ich habe für / port 8080 eingeben (da läuft ja der WS)

Da ich den nginx-proxy-manager auf jedenfall verwenden möchte - da er mir viele andere websiten published - kämpfe ich hier dem dieser konfig... :-(

Gruß
Thorsten

Hallo Thorsten,
bist du denn mit deiner Lösung schon weitergekommen?
Ich wäre hier auch sehr interessiert und habe es auch schon erfolglos probiert den NGINX Proxy Manager zu konfigurieren :-(

Viele Grüsse
Eric

[ThorstenGehrig]

Hi

Willst du Webseiten und websocket am selben Port nutzen, wie ich es möchte, oder soll der websocket bei dir auf 8080 bleiben?

Der Websocket kann auch 8080 bleiben - zumindest hatte ich das auch so bei Apache als reverse proxy.
Der reverse-proxy ist in erster linie security: ich hab da alle meine Webseiten gepublished (ubnifi, unraid, edomi, webcams, ...)- abgesichert durch client-zertifikat-authentifizierung.

Der WS auf 443 erfordert ja eine anpassung am Apache auf dem EDOMI - da will ich eigentlich so nah wie möglich am default bleiben.
Gruß
Thorsten

[starwarsfan]

Hallo miteinander

Bei mir läuft folgendes schon sehr lange ganz wunderbar (ebenfalls mit CC-Zertifikaten) mit einem nginx-RevProxy in der DMZ:

Musstest Du dafür am Edomi-Apachen etwas anpassen?

[saegefisch]

starwarsfan Nein, Yves, edomi lief und läuft bei mir immer out-of-the-Box. Habe daran noch nie geschraubt, was nicht in der Basiskonfig geht. Und selbst da nur wenig; zumindest nie die Ports. Edomi ist bei mir immer pur, außer LBS-Erfordernisse.

Und das hat funktionierte mit edomi LXC ebenso wie jetzt kürzlich nach dem Umzug zurück auf mein neues dediziertes edomi NUC-Blech.
im revProxy nur die übliche .cfg angepasst, konkret die IP für Server und websocket vom LXC auf NUC, nginx restart. Fertig.

keine Ahnung, was dieser proxymanager ist, ich arbeite nur an der nginx.cfg und habe persönlich noch nichts vermisst, weil stabil (System: cubieboard mit ubuntu 18.04 LTS) Für diverse subdomains/Dienste, alle mit Client Certificates. Funktioniert seit vielen Jahren (2016? Keine Ahnung, siehe meine Fragen und Lösungen im Forum damals) problemlos. Sehr regelmäßig nur Updates und über die Jahre immer mal Verschärfung der ciphers/TLS und anderer Sicherheits-Kleinigkeiten damit ich mein „A+„ halte.

von außen natürlich nur https (LE-Zertifikate), innen wo möglich auch https, bei edomi halt nur http. Im LAN eigene server-Zertifikate, genau wie die Client Zertifikate.

[givemeone]

Ich habe in neueren Versionen des Docker Images auch nichts mehr am Edomi-Apache angepasst.
Aber das musste ich damals auch nur, wenn ich explizit Port 443 nutzen wollte.
Alle anderen Ports haben immer schon direkt funktioniert.

[ThorstenGehrig]

Hi
ich versuche das "mal anders" anzugehen.
Frage: weiß jemand warum der EDOMI Websocket nicht auf Port 80 läuft? (zusammen mit dem Webserver)?
Ich habe mich mit Websockets ein bisschen eingelesen - und man findet das es durchaus sinnvoll ist die WS auf Port 80 bzw. 443 direkt laufen zu lassen - zusammen mit der Website.
Ich vermute es gibt einen Grund warum EDOMI auf 80 und WS-8080 läuft? gaert ... kannst du hier was sagen?
Gruß
Thorsten

[Glotzkowski]

Frage: weiß jemand warum der EDOMI Websocket nicht auf Port 80 läuft?

Ich würde spontan sagen, dass zwei Anwendungen nicht auf sem selben Port hören können, da das OS sonst nicht weiß zu welcher Anwendung die auf der Netzwerkkarte eingehenden Daten geleitet werden müssen oder habe ich Deine Frage diesbezüglich falsch verstanden?

Wenn beides von der gleichen Anwendung bedient wird, sollte das kein Problen sein, da hier dann die Unterscheidung stattfinden kann, bei EDOMI ist aber Port 80 der HTTP-Server und Port 8080 der Websocket-Server (php-Prozess).

[ThorstenGehrig]

Ich würde spontan sagen, dass zwei Anwendungen nicht auf sem selben Port hören können, da das OS sonst nicht weiß zu welcher Anwendung die auf der Netzwerkkarte eingehenden.

Laut Wikipedia ist das nicht der Fall: https://de.wikipedia.org/wiki/WebSocket
Zitat: "...was die Nutzung des Standard-HTTP-Ports „80“ zugleich für normale HTTP-Kommunikation als auch für die Websocket-Nutzung ermöglicht."

Genau hier scheint mein Problem zu legen. Der Nging reverse proxy erlaubt per default ein "support upgrade to Websocket" - aber wohl nur auf dem selben port...

Gruß
Thorsten

[jonofe]

Mit einem

lsof -P | grep LISTEN | grep \:80

kann man leicht sehen, dass php den Port 8080 (websocket) bindet und apache den Port 80 (Webserver).
EDOMI müsste einen eigenen PHP Webserver implementieren, damit EDOMI sowohl web und websocket Traffic auf demselben Port bedienen kann. Bei TCP kann, wie schon von Glotzkowski angemerkt, ein Port immer nur an einen Prozess gebunden sein.

Was genau kann denn der apache ReverseProxy nicht, was NGINX Reverse Proxy Manager kann?
Was ich schon seltsam fände, das der NGINX Reverse Proxy Manager etwas nicht kann, was NGINX an sich kann.

[philipp900]

Ich verwende zwar nicht den Proxy Manger aber nginx.
Um alles über https Port 443 laufen lassen zu können ohne dafür Edomi anzupassen, ändere ich mittels sub_filter den Connection-String des javascript files der Visu bei Auslieferung über den Proxy.

# Edomi Visu
location /visu/ {
sub_filter "WebSocket(serverProtocol+'://'+serverIp+':'+serverPort)" "WebSocket(serverProtocol+'://'+serverIp+':443/wss')";
sub_filter_types application/javascript;
sub_filter_once off;
proxy_pass http://192.168.0.50/visu/;
}

# Edomi Visu WebSocket
location =/wss {
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_pass http://192.168.0.50:8080;
}