Nginx als Reverse Proxy mit websocket für FHEM

[CoolTux]

Hallo Stefan,

Hast Du wirklich das ganze global Device in FHEM gelöscht oder habe ich Dich da falsch verstanden?
Das bitte nicht machen. Alles was du machen musst ist testen ob du normal auf FHEM kommst, also von innen. Wenn das geht stellst du den Reverse Proxy ein.

Unter server_name gehört der externe DNS Name, also genau so wie Du FHEM von aussen aufrufen tust.

[Karflyer]

Hallo CoolTux,

nein, das hast du Missverstanden. Nicht das global-Device sonder der Zusatz im FHEMWEB. z.B. 'define WEB FHEMWEB 8083 global'.
Zu diesem 'global' steht im entsprechenden WIKI-Beitrag, dass man es mit dem aufsetzen des Reverse-Proxy entfernen soll.
Zitat aus dem WIKI https://wiki.fhem.de/wiki/HTTPS-Absicherung_%26_Authentifizierung_via_nginx_Webserver "In der FHEM-Konfiguration muss sichergestellt werden, dass kein Client außerhalb des Servers zugreifen kann. Dazu muss das normalerweise gesetzte Flag global von jeglicher Konfiguration entfernt werden." Wie ich geschrieben habe, wenn ich dieses 'global' entferne, habe ich keinen Zugriff mehr auf FHEM.

[CoolTux]

Hallo CoolTux,

nein, das hast du Missverstanden. Nicht das global-Device sonder der Zusatz im FHEMWEB. z.B. 'define WEB FHEMWEB 8083 global'.
Zu diesem 'global' steht im entsprechenden WIKI-Beitrag, dass man es mit dem aufsetzen des Reverse-Proxy entfernen soll.
Zitat aus dem WIKI https://wiki.fhem.de/wiki/HTTPS-Absicherung_%26_Authentifizierung_via_nginx_Webserver "In der FHEM-Konfiguration muss sichergestellt werden, dass kein Client außerhalb des Servers zugreifen kann. Dazu muss das normalerweise gesetzte Flag global von jeglicher Konfiguration entfernt werden." Wie ich geschrieben habe, wenn ich dieses 'global' entferne, habe ich keinen Zugriff mehr auf FHEM.

Ok jetzt verstehe ich. Das ist etwas Missverständlich ausgedrückt. Allerdings hättest Du Dir nur mal die commandref zu FHEMWEB durchlesen brauchen. Wenn Du global löschst werden nur noch Verbindungsanfragen vom localhost angenommen. Das macht bei einem Reverse Proxy Sinn wenn dieser local auf dem FHEM Server läuft, was ja bei Dir nicht der Fall ist. Lese mal das hier bitte, dann verstehst Du bestimmt
http://commandref.fhem.de/commandref_DE.html#FHEMWEB

[Karflyer]

OK. Vielen Dank. Ich habe schon stundenlang gelesen. Aber wie sagt man so treffend 'manchmal sieht man vor lauter Bäumen den Wald nicht mehr  .
Kannst du mir bitte noch etwas zu meiner zweiten Frage sagen.
In der Konfigdatei zum Reverse-Proxy steht im Abschnitt 'server' der Eintrag server_name. Im WIKI-Beitrag beispielsweise 'server_name fhempi;'

Code: [Auswählen]

server {

    listen 443;
    server_name fhempi;
Welcher Name ist hier einzutragen? Der vom Host auf dem NGINX läuft, oder der auf dem FHEM läuft oder der DynDNS-Domainname...
Mir ist nicht klar, wo dieser Eintrag zum tragen kommt.

[CoolTux]

Unter server_name gehört der externe DNS Name, also genau so wie Du FHEM von aussen aufrufen tust.

[clickme]

Hallo,

ich habe hier mal meine SSL Conf des nginX. Diese Konfiguration schafft bei SSL Labs ein Rating von A+ - was das momentane maximum ist.

Code: [Auswählen]

server {
    listen 80;
    return 301 https://$host$request_uri;
}

server {

    listen 443;
    server_name fhem.domain.com;

    ssl_certificate           /etc/letsencrypt/live/fhem.domain.com/fullchain.pem;
    ssl_certificate_key       /etc/letsencrypt/live/fhem.domain.com/privkey.pem;

    ssl on;
    ssl_session_cache  builtin:1000  shared:SSL:10m;
    ssl_session_timeout 10m;
    ssl_session_cache shared:SSL:10m;
    ssl_session_tickets off;
    ssl_dhparam /etc/ssl/dhparams_4096.pem;
    ssl_ecdh_curve secp384r1;
    ssl_stapling on;
    ssl_stapling_verify on;
    ssl_protocols TLSv1.2;
    ssl_ciphers ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384;
    ssl_prefer_server_ciphers on;

    resolver 8.8.8.8 8.8.4.4 valid=300s;
    resolver_timeout 5s;

    add_header Public-Key-Pins 'pin-sha256="<PRIMÄREN PIN>"; pin-sha256="<BACKUP PIN>"; max-$
    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload";
    add_header X-Frame-Options DENY;
    add_header X-Content-Type-Options nosniff;
    add_header X-XSS-Protection "1; mode=block";
    add_header X-Robots-Tag none;

    access_log            /var/log/nginx/fhem.access.log;

    location / {

      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;
      proxy_http_version      1.1;

      proxy_pass          http://localhost:8083;
      proxy_read_timeout  90;

      auth_basic "Restricted Content";
      auth_basic_user_file /etc/nginx/.htpasswd;
    }

Ausgang des ganzen war die Config hier aus dem Wiki - daher möchte ich es zurück geben. Die Unterscheidung nach Useragent brauche ich nicht.

Mir ist bewusst, dass die SSL Ciphers / SSL Protokolle sehr "streng" ausgedünnt sind, aber meine Apple Devices kommen damit gut zurecht. Für niemand anders ist die Seite ja

[Loredo]

Zum Thema iOS wäre noch anzumerken, dass ein selbst signiertes Zertifikat nicht funktioniert. iOS verlangt für websocket ein valides Zertifikat, ansonsten wird eine Websocket Verbindung mit "OSStatus error -9807" abgelehnt.

[CoolTux]

Kann man bei iOS wenigstens ein selbst erstelltes rootCA importieren?

[Loredo]

Klar das geht :-)

[JoeALLb]

ich habe hier mal meine SSL Conf des nginX. Diese Konfiguration schafft bei SSL Labs ein Rating von A+ - was das momentane maximum ist.

Servus Max,

in der Zeile

Code: [Auswählen]

add_header Public-Key-Pins 'pin ..fehlt das schließende '. Dafür steht dort dein Loginname....

Bei Dir funktioniert soweit alles? Mei mir bleibt manchmal der Firefox hängen, während er Daten vom Websocket laden möchte...


sG
Joe

[der_oBi]

Moin zusammen,

ich krame diesen Uralt-Thread mal wieder hervor.
Ich habe auch vor, mein FHEMWEB per nginx Reverse Proxy mit SSL abzusichern.
Ich verzweifle momentan aber daran, longpoll per Websocket zum Laufen zu bringen. Ich habe auch alle in diesem Thread beschriebenen Varianten mehrmals durchprobiert, ohne Erfolg.
Ohne den Umweg über nginx funktioniert Websocket prima.

Muss ich außer dem Paket nginx noch etwas installieren?
Das Ganze läuft übrigens auf einem Debian 9.5 (unter proxmox).

Wäre über Hilfe echt dankbar 

[CoolTux]

Das hier habe ich in meiner /etc/nginx/sites-enabled/fhem-reverseproxy damit funktioniert Websocket super.
Kann sein das ich noch was in die /etc/nginx/nginx.conf dazu habe, aber das weiß ich aktuell nicht mehr. Probier erstmal das.
Entferne aber Dinge die Du nicht brauchst. Sowas wie die Zertifikate oder ändere die Einträge. Ich habe vieles noch mit dazu genommen was die Verbindung sicherer machen soll.

Code: [Auswählen]

server {

        listen 443 http2;
        listen [::]:443 http2;
        server_name fhem-xxx.xxx.net;

        # Add headers to serve security related headers
        # Before enabling Strict-Transport-Security headers please read into this
        # topic first.
        add_header Strict-Transport-Security "max-age=15768000";
        add_header X-Frame-Options SAMEORIGIN;
        add_header X-Content-Type-Options nosniff;
        add_header X-XSS-Protection "1; mode=block";
        add_header X-Robots-Tag none;
        add_header X-Download-Options noopen;
        add_header X-Permitted-Cross-Domain-Policies none;


        ssl_certificate           /etc/nginx/certs/fhemCert.pm;
        ssl_certificate_key       /etc/nginx/certs/fhemKey.pm;

        ssl on;
        ssl_session_cache  builtin:1000  shared:SSL:10m;
        ssl_session_timeout 10m;
        ssl_session_cache shared:SSL:10m;
        ssl_session_tickets off;
        ssl_ecdh_curve secp384r1;
        ssl_stapling on;
        ssl_stapling_verify on;
        ssl_protocols TLSv1.2;
        ssl_ciphers ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384;
        ssl_prefer_server_ciphers on;






        access_log            /var/log/nginx/fhem-reverseproxy/access.log;
        error_log             /var/log/nginx/fhem-reverseproxy/error.log;




        location / {

                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;
                proxy_http_version      1.1;

                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection $connection_upgrade;


                proxy_pass          http://fhem01.tuxnet.local:8083;
                #proxy_read_timeout  90;
                proxy_read_timeout  86400;
                proxy_buffering     off;

                auth_basic "Restricted Content";
                auth_basic_user_file /etc/nginx/.htpasswd;

                proxy_redirect      http://fhem01.tuxnet.local:8083 http://fhem-xxx.xxx.net;
        }
}

[hexenmeister]

Ich habe gute Erfahrung mit dem Docker-Container linuxserver/letsencrypt
Dort befinden sich bereit weitgehend vorkonfigurierte nginx und certbot zum automatischen Abruf unf Aktualisierung von Letsencrypt-SSL-Zertifikaten (und noch paar nette Suchen mehr, wie z.B. fail2ban).

Damit laufen bei mir mehrere FHEM-Instanzen, NodeRed und Grafana hinter dem Reverse-Proxy.

Auf Wunsch kann ich die docker-compose-Datei und Proxy-Einstellungen für den FHEM gern bereitstellen.

[Wernieman]

Wobei ich gestehen würde, das ich z.B. fail2ban nicht im gleichen Container laufen lassen würde. Ein Container sollte ein Dienst sein. NGINX + fail2ban aber eigentlich 2....

[FunkOdyssey]

Auf Wunsch kann ich die docker-compose-Datei und Proxy-Einstellungen für den FHEM gern bereitstellen.

Gerne ja. Deine Variante würde mich auch interessieren.