Reverse Proxy

[psilo]

Max2612 hää?? Du kommst bspw. vom Handy aus dem Mobilfunknetz drauf, aber nicht von einem Browser im LAN? Kannst Du Deine Domain pingen? Das klingt mir ziemlich faul... Wie testest Du denn überhaupt, von "extern" zu schalten???

Egal wo Du bist wird eine Anfrage ins "Internet" gemacht. Außer Dein LAN lässt Dich nicht raus... :> Dann könntest Du hier aber auch nicht posten.

[Max2612]

PS: ruf die Visu "intern" doch einfach auch über Deine Domain auf. Gehst Du "intern" auf "http"? Dann kann es nicht gehen:

ich glaube die Websocket Verbindung sucht sich das ws oder wss je nach http oder https aus mit dem die SmartVISU aufgerufen wurde.

Und die Websockets gehen dann ja auf deine Domain.. und Port 80 ist zu..

ruf die IP mal mit https auf.. dann sagt er zwar das Zertifikat ist falsch, aber es sollte trotzdem gehen.

Intern komme ich aber über "https://meine-domain/smartVISU" garnicht drauf. Da meldet der Browser: Die Website ist nicht erreichbar.

[psilo]

PS: ruf die Visu "intern" doch einfach auch über Deine Domain - also von extern - auf. die Websockets bleiben ja sowieso gegen die Domain konfiguriert.. Performancetechnisch bringt das also nicht viel.

Gehst Du "intern" mit der IP auf "http"? Dann kann es nicht gehen:

ich glaube die Websocket Verbindung sucht sich das ws oder wss je nach http oder https aus mit dem die SmartVISU aufgerufen wurde.

Und die Websockets gehen dann ja auf deine Domain.. und Port 80 ist zu..

ruf die IP mal mit https auf.. dann sagt er zwar das Zertifikat ist falsch, aber es sollte trotzdem gehen. In meinem Fall habe ich auf dem NAS ein lokales Zertifikat, so dass die lokale IP auch mit https "kann"..

[psilo]

Max2612 In der Anleitung steht ja, dass Port 80 nur bis zur Let's Encrypt Zertifikateerstellung offen sein sollte - Beim Verlängern nach 3 Monaten musst Du sie auch wieder aufmachen glaube ich.. Ich muss das aber nochmal testen. Ich hätte gerne noch eine automatische Erneuerung.. Was mit Zwang zu Port 80 dann nicht gehen würde, da ich ja am Router öffnen muss..

Für den Betrieb würde ich wie beschrieben in der default Datei für NGINX auf Port 80 einen HTTP Error Code zurückgeben (auch wenn ohne Weiterleitung keiner draufkommen sollte - aber ich bin manchmal etwas paranoid..)

Was sagt denn die Webentwickler Console (F12) wo die Websocket Requests hingehen?

[Max2612]

1. Wieso definierst du ein explizites listen für http? Im Gegenteil solltest du gemäss Anleitung dieses sogar in den Defaulteinstellungen entfernen.
Andererseits kann man das natürlich auch als Feature nutzen: Aus dem LAN nutzt man http ohne Authentisierung, im Router gibt man dann Port 443 für die Nutzung azs dem Internet frei. Das geht aber erst mit der kommenden Version der smartVISU, wegen dem dynamischen Port.

2. Als Hostname gibst du deine Dyndns-Adresse ein, als Port 443.
In der kommenden Version kann man einfach beide Felder leer lassen, dann werden diejenigen der Website verwendet.

1. Ist gelöst. Im Router war noch Port 80 weitergeleitet.
2. Das klappt aber trotzdem nicht. "Could not connect to sh.py Server"

Edit: Von extern, kann ich jetzt schalten. Aber intern über "192.168.1.13/smartVISU" bleibt der Fehler!

[smai]

1. Wieso definierst du ein explizites listen für http? Im Gegenteil solltest du gemäss Anleitung dieses sogar in den Defaulteinstellungen entfernen.
Andererseits kann man das natürlich auch als Feature nutzen: Aus dem LAN nutzt man http ohne Authentisierung, im Router gibt man dann Port 443 für die Nutzung azs dem Internet frei. Das geht aber erst mit der kommenden Version der smartVISU, wegen dem dynamischen Port.

2. Als Hostname gibst du deine Dyndns-Adresse ein, als Port 443.
In der kommenden Version kann man einfach beide Felder leer lassen, dann werden diejenigen der Website verwendet.

[Max2612]

Hallo,

ich bin jetzt bei der Konfiguration dem neuen Beispiel gefolgt.
2 Fragen bleiben aber noch offen.

1. Beim externen Aufruf über https kommt die Frage nach Bentzer und Passwort. Soll ja auch so sein.
Aber über http komme ich gleich zur Visu. Das sollte doch nicht sein, oder?

2. Wie muss jetzt die Einstellung in der sv (2.8) ausschauen, dass die websockets funktionieren?

Meine conf

server {
        listen 80 default_server;
        listen [::]:80 default_server;
       # include /etc/nginx/snippets/letsencrypt.conf;
}

server {
    server_tokens off;

    listen 443 ssl default_server;
    server_name xxx.spdns.org;

    ##
    # SSL
    ##

    ssl on;
    ssl_certificate /etc/letsencrypt/live/xxx.spdns.org/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/xxx.spdns.org/privkey.pem;
    ssl_session_cache builtin:1000 shared:SSL:10m;
    ssl_ciphers    HIGH:!aNULL:!eNULL:!LOW:!3DES:!MD5:!RC4;

    add_header Strict-Transport-Security "max-age 31536000; includeSubDomains";

    ##
    # global
    ##

    root /var/www/html/xxx.spdns.org;
    index index.php index.htm index.html;

  location / {
        auth_basic "Restricted Area: smartVISU";
        auth_basic_user_file /etc/nginx/htpasswd.smartvisu;

        # Nur Websocket Verbindungen gegen "/" durchlassen!
        if ($http_upgrade = websocket) {
                proxy_pass http://192.168.1.13:2424;
        }
        if ($http_upgrade != websocket) {
                return 403;
        }
    }

  location /smartVISU {

        auth_basic "Restricted Area: smartVISU";
        auth_basic_user_file /etc/nginx/htpasswd.smartvisu;

    proxy_pass http://192.168.1.13/smartVISU;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

  location /smartVISU2.9 {

        # auth_basic "Restricted Area: smartVISU";
        # auth_basic_user_file /etc/nginx/htpasswd.smartvisu;

    proxy_pass http://192.168.1.13/smartVISU2.9;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }


  location /alexa {
        auth_basic "Restricted Area: Alexa";
        auth_basic_user_file /etc/nginx/htpasswd.alexa;

        proxy_pass http://192.168.1.13:9000/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }  


}

[psilo]

So, ich habe mal die Clientzertifikate ergänzt. Ist leider ein bischen ein "Gefrickel" die zu erstellen. Wäre klasse wenn das mal jemand nachtesten kann..

Das mit dem SSH Port habe ich rausgeworfen und im Beispiel jetzt 3 Passwort-Files angegeben (was mE. Sinn macht).

https://github.com/smarthomeNG/smart...s-ReverseProxy

[psilo]

TCr82 ich hatte bei mir eine Zeit lang eine öffentliche Seite ohne basic auth online (die von AWS für Alexa geforderte privacy Seite - ich hatte gedacht, die MUSS online sein. ist wohl aber doch nicht so). Da macht das mit den Referren mehr Sinn. Es schadet aber auch nicht?! Daher lieber zu viel als zu wenig.

Zu den basic auths: ich habe für Alexa, das Network Plugin, die SmartVISU und meine Synology Photo Station unterschiedliche Files.. Auch da macht es Sinn mehrere Einträge zu haben. Ich will ja nicht, dass jeder der die Photos ansehen darf, auch Zugriff auf die Haussteuerung hat..

Ich wollte das Beispiel aber einfacher halten, so detailliere ich das jetzt aber besser doch..

[TCr82]

     ## Deny certain Referers ##     if ( $http_referer ~* (babes|forsale|girl|jewelry|love|nudit|organic|poker|porn|sex|teen) )     {         return 403;     }

meinst du wirklich dass macht noch alles sinn (von dem hier mal ganz abgesehen, was für mich noch weniger sinn macht), wenn die komplette Seite sowieso per Basic Auth und SSL gesichert ist?

Naja, die Ländersperre kann ich noch dann verstehen, wenn man kein Ultra-Sicheres Passwort für das Auth gewählt hat...

Genauso machst du dann noch zu dem Auth auf / ein Auth auf /smartVISU usw, obwohl das doch von / vererbt wurde?! Ist halt irgendwie alles doppel und dreifach gemoppelt

[psilo]

Anbei meine auf "Raspbian Stretch" aktualisierte Anleitung. Aktuell nur mit Basic Auth (geht bei Websockets wirklich):
https://github.com/smarthomeNG/smart...s-ReverseProxy

Speziell das Zeug mit Certbot ging mit Stretch etwas anders. Checkt man das GIT von Letsencrypt aus, gibt es derzeit einen Bug beim Zertifikategenerieren.

Die Anleitung für Clientzertifikate schreibe ich am Wochenende

[TCr82]

EDIT: Nachdem ich deinen Beitrag nochmal gelesen habe, denke ich, dass du die Korrektur von letzter Nacht noch nicht gepulled hast.
Zuvor wurde der Port nämlich fälschlicherweise bei jedem Öffnen der Config-Seite zurückgesetzt (egal ob leer oder nicht).

Stimmt so wars. Das war wohl das Problem.

[psilo]

TCr82 ok ich war der meinung, ich müsste das bei der konfiguration der websocketverbindung mit angeben.. aber du hast recht, wenn der browser checkt, dass er die über den normalen abruf der seiten gesetzte basic auth verwendet, muss man das nicht... ich teste das die tage mal mit nginx durch.

[TCr82]

TCr82 funktioniert die Basic Auth bei Dir auch bei Websockets? [...]
Falls Basic Auth doch geht: wie gibst du die in der SV an?

user:password@...?

Hi, also das Basic Auth geht auch mit Websockets, wobei der Browser für Websocket-Zugriffe keinen Auth-Dialog bringt und somit immer nur ein Error 401 zurückgibt beim Zugriff auf den Server. Aber wenn man vorher Angemeldet wurde funktioniert der Zugriff auch automatisch, da der Server die entsprechenden Header mitsendet.

Und wieso muss ich die in der SV angeben? Du meist für die Anmeldung für die Websockets? Wenn ja, geht das Automatisch, sobald man von dem Zugriff auf die Webseite der Visu angemeldet wurde.

Gruß

[psilo]

Wen es interessiert: ich baue über die nächsten Tage unter https://github.com/smarthomeNG/smart...s-ReverseProxy mal Doku auf, wie man einen hardwaretechnisch autonomen ReverseProxy mit NGINX aufbaut..

Erweiterungen und Anmerkungen gerne an mich.