FHEM Forum

FHEM - Hardware => Server - Linux => Thema gestartet von: h3llsp4wn am 16 Februar 2017, 14:37:53

Titel: Nginx als Reverse Proxy mit websocket für FHEM
Beitrag von: h3llsp4wn am 16 Februar 2017, 14:37:53
Hallo zusammen,

u.a. da ich FHEM hinter nginx betreibe und auch die TabletUI gerne auf websocket umstellen wollte, stellt sich mir die Frage bzgl. Konfiguration von nginx. Nun bin ich da leider
kein Experte - allerdings kann ich entweder nur FHEM hinter dem Proxy erreichen oder dann nur den websocket - beides an localhost:8083 zu binden klappt nicht. Dazu müsste
ich ggf. eine anderen Entry-Point haben, d.h. eine location für fhem (/fhem) und dann ggf. eine für den websocket (/fhem_ws) o.ä. - soweit ich das verstehen. Im Apache
könnte man da wohl mir rewrite rules was basteln. Ich möchte allerdings, da ich auch noch andere Dinge laufen habe nicht wieder alles auf Apache umbauen.

Daher die Frage - nutzt jemand ggf. nginx als reverse proxy und hat hier auch die websockets ans laufen bekommen - und wenn ja, wie?


Cheers,

h3ll
Titel: Antw:Nginx als Reverse Proxy mit websocket für FHEM
Beitrag von: vbs am 16 Februar 2017, 15:06:17
Zeig doch mal deine Konfiguration...
Titel: Antw:Nginx als Reverse Proxy mit websocket für FHEM
Beitrag von: h3llsp4wn am 16 Februar 2017, 16:45:10
Stimm - guter Hinweis :)


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

upstream fhem {
server localhost:8083;
}

server {
        #listen   80; ## listen for ipv4; this line is default and implied
        #listen   [::]:80 default_server ipv6only=on; ## listen for ipv6

        root /var/www;
        index index.html index.htm index.php;

        # Make site accessible from http://localhost/
        server_name localhost raspberrypi.fritz.box raspberrypi;

        location /fhem {
access_log off;

                proxy_pass http://localhost:8083;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
#proxy_read_timeout 150;
                proxy_redirect off;
                proxy_buffering off;
}
...


Den timeout hatte ich mal zum Test gesetzt ... wenn ich es so laufen lasse und im FHEM longpoll auf websocket setze, dann kann ich verbinden, aber meine Aufruf direkt ohne Port über den Proxy
gibt keine Rückmeldung mehr.
Titel: Antw:Nginx als Reverse Proxy mit websocket für FHEM
Beitrag von: vbs am 16 Februar 2017, 18:48:21
Vielleicht kannst du dir was mit der Variable $server_protocol und einem "if" basteln, aber besser wärs wie du ja auch schon gesagt hast, wenn die beiden Diensten unter getrennten locations erreichbar wären. Google bringt aber sofort "if is evil" :D https://www.nginx.com/resources/wiki/start/topics/depth/ifisevil/
Titel: Antw:Nginx als Reverse Proxy mit websocket für FHEM
Beitrag von: h3llsp4wn am 17 Februar 2017, 09:12:15
Danke - service_protocol hatte ich gar nicht auf dem Schirm ... evil if habe ich auch schon gesehen  >:(, das wollte ich verhindern - trotzdem danke - ich werde es mal damit versuchen  ;).

Nachtrag - so läuft es jetzt bei mir - mit einem evil if und dem check gegen das upgrade. Der Umweg über die Variablen ist erforderlich, da nginx das setzen im if dieser Attribute nicht zulässt ... also
quasi auch schon wieder ein hack. Wer eine bessere Idee hat - her damit.

Anbei der fhem Block:


        location /fhem {
                access_log off;

                set $bla_remote_addr "";
                set $bla_proxy_add_x_forwarded_for "";
                set $bla_upgrade "";
                set $bla_connection "";
                set $bla_header "";

                if ($http_upgrade = "websocket") {
                        set $bla_remote_addr $remote_addr;
                        set $bla_proxy_add_x_forwarded_for $proxy_add_x_forwarded_for;
                        set $bla_upgrade $http_upgrade;
                        set $bla_connection "upgrade";
                        set $bla_header $host;
                }

                proxy_pass http://localhost:8083;
                proxy_set_header X-Real-IP $bla_remote_addr;
                proxy_set_header X-Forwarded-For $bla_proxy_add_x_forwarded_for;
                proxy_http_version 1.1;
                proxy_set_header Upgrade $bla_upgrade;
                proxy_set_header Connection $bla_connection;
                proxy_set_header Host $bla_header;
                proxy_redirect off;
                proxy_buffering off;
        }

Titel: Antw:Nginx als Reverse Proxy mit websocket für FHEM
Beitrag von: All-Ex am 18 Februar 2017, 00:18:03
Habe das bei mir nicht hinbekommen. Du lässt bei deiner if-Lösung dann den map Befehl weg oder?

Wieso bleiben denn bei allen Verbindungen ohne connection upgrade die $bla Variablen auf ""?
Titel: Antw:Nginx als Reverse Proxy mit websocket für FHEM
Beitrag von: h3llsp4wn am 26 Februar 2017, 16:01:07
Hm ... weil ich diese dann nicht brauche? Bin aber kein Experte. So funktioniert es zumindest bei mir. D.h. eine richtige Antwort habe ich da nicht.
Titel: Antw:Nginx als Reverse Proxy mit websocket für FHEM
Beitrag von: dela2017 am 28 Februar 2017, 00:32:23
Hi Hellspawn,

hast du vielleicht noch irgendeine Besonderheit?
Ich möchte eigentlich wohl das gleiche wie du; ich hab deinen Teil der Konfig übernommen, aber dennoch verliert die TabletUI immer die Connection; bzw. auch auf der FHEM Hauptseite erscheint praktisch die ganze Zeit: Connection lost, trying a reconnect every 5 seconds

Gruß,
Ingo
Titel: Antw:Nginx als Reverse Proxy mit websocket für FHEM
Beitrag von: Civicoid am 10 März 2017, 19:08:27
Danke für den Code!
Nun läuft mein FHEM wieder flüssig über NGINX.

8)
Titel: Antw:Nginx als Reverse Proxy mit websocket für FHEM
Beitrag von: Klouse am 24 April 2017, 15:59:19
Hallo,

grundsätzlich scheint es zu funktionieren, leider erhalte ich jedoch ebenso wie dela2017 regelmäßig disconnect Meldungen.

Hat noch jemand einen Tipp für uns?

Danke!

LG,
Klaus
Titel: Antw:Nginx als Reverse Proxy mit websocket für FHEM
Beitrag von: sickboy79 am 28 April 2017, 17:03:35
Hi,

Danke h3llsp4wn für deine Konfiguration. Ich habe mal eine Konfiguration basierend auf der NGINX Anleitung im Wiki und deiner Konfiguration für das Thema Websockets als Vorschlag mal im Wiki zusammengetragen.

https://wiki.fhem.de/wiki/Diskussion:HTTPS-Absicherung_%26_Authentifizierung_via_nginx_Webserver

Was meint ihr? Aktuell kann ich noch keine Verbindungsabbrüche beobachten.

LG,
Tobias
Titel: Antw:Nginx als Reverse Proxy mit websocket für FHEM
Beitrag von: vbs am 28 April 2017, 19:59:07
Das hier macht mir wie gesagt Sorgen (und ist auch der Grund warum ich es nicht nutze):
https://www.nginx.com/resources/wiki/start/topics/depth/ifisevil/

Titel: Antw:Nginx als Reverse Proxy mit websocket für FHEM
Beitrag von: sickboy79 am 29 April 2017, 01:34:22
Hi VBS,

so lange es bei einem if block bleibt sehe ich an dieser Stelle kein Problem. Natürlich gäbe es alternativen mit zusätzlichen nginx modulen, aber die gezeigte Konfiguration wird bei mehr als 90 % der Anwendungen ohne Probleme funktionieren.

If is not so evil afterall if you understand how it works :-)

Titel: Antw:Nginx als Reverse Proxy mit websocket für FHEM
Beitrag von: flocki am 29 April 2017, 09:08:15
Guten Morgen,
ich habe jetzt schon diverse Foreneinträge ausprobiert und auch im Internet gesucht, aber bisher habe ich nichts gefunden.
Habe das problem das ich zwar fhem angezeigt bekomme, aber nur das menü als Text auf weißem Hintergrund und ohne Funktion.
Scheint als ob css nicht weiter durch gegeben werden.

Habe eine RP1 auf dem der NginX V1.6.2 (Selbstkompilierte Version 1.9.9 funktionerte genauso wenig) als ReverseProxy mit https läuft und alle Anfragen zum RP3 wo fhem läuft weitergibt an FHEMWEB auf Port 8086 (diesen nur für interne Anfragen freigegeben und daher ohne Passwort und ohne Attr. HTTPS.

Hier mal mein Code vom Reverse Proxy

nginx.con (Funktioniert soweit, hier komme ich auch andere Geräte im Net von außerhalb)

worker_processes  1;

events {
    worker_connections  1024;
}


http {
    # HTTP Basic Authentication
    auth_basic "watchdog";
    auth_basic_user_file .htpasswd;


# SSL Zertifikate von letsencrypt
ssl_certificate /etc/letsencrypt/live/Domain.de/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/Domain.de/privkey.pem;

    server_tokens off;

    include       mime.types;
    default_type  application/octet-stream;

include sites-enabled/*;

    sendfile        on;
   
    keepalive_timeout  65;

    #gzip  on;

# Standard Server Port 80 mit umleitung auf 443
    server {
listen 80 default_server;
        return 301 https://$host;
        }

# Standard Server mit Port 443
    server {
        listen       443 ssl default_server;

#server_name Domain.de;
        server_name  localhost;

         location / {
            root   /var/www/html;
            index  index.html index.htm;
        }
    }
}


fehm.conf

server {
listen 443 ssl;
server_name fhem.*;
location / {
  set $my_http_upgrade "";
  set $my_connection "Connection";
 
  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 $my_http_upgrade;
  proxy_set_header Connection $my_connection;
 
  if ($http_upgrade = "websocket") {
set $my_http_upgrade $http_upgrade;
set $my_connection "upgrade";
  }

  proxy_pass http://fhem-IP:8086/fhem;
  proxy_read_timeout 20736000;
  proxy_buffering off;
}
}


Habt Ihr einen Tipp für mich was ich noch versuchen könnte?
Titel: Antw:Nginx als Reverse Proxy mit websocket für FHEM
Beitrag von: fiedel am 30 April 2017, 09:22:59
Hi flocki,

bei mir läuft die angehängte, selbst zusammengesuchte config problemlos mit NGINX 1.11.12 (kompiliert) und "standard FHEMWEB". Die aus unserem WIKI habe ich nicht ans Laufen bekommen.  Gleichzeitig können die Spezis ja mal drübergucken, ob grobe Sicherheitsschnitzer drin sind (z.B. ob die freigegebenen TLS- Versionen und Verschlüsselungsalg. noch sicher sind).

Gruß
Frank
Titel: Antw:Nginx als Reverse Proxy mit websocket für FHEM
Beitrag von: flocki am 01 Mai 2017, 16:32:05
Hallo Frank,
danke für deine Antwort.

Bei dir ist aber fhem und der reverse proxy auf einem Gerät, oder?

Bei mir sind beide auf getrennten Geräten (Raspberry Pi).

Und ich glaube hier liegt auch das Problem.
Jetzt bekomme ich nämlich nur noch einen 504 Fehler angezeigt, komisch ist auch das fhem das einzige Geät ist das nicht funktioniert.
Komme soga auf meinen PiHole (3. Pi) mit https ohne Probleme.
VG Heiko
Titel: Antw:Nginx als Reverse Proxy mit websocket für FHEM
Beitrag von: fiedel am 02 Mai 2017, 08:33:29
Zitat von: flocki am 01 Mai 2017, 16:32:05
Bei dir ist aber fhem und der reverse proxy auf einem Gerät, oder?
So ist es.  :)

Titel: Antw:Nginx als Reverse Proxy mit websocket für FHEM
Beitrag von: JoeALLb am 02 Mai 2017, 09:54:34
Zitat von: sickboy79 am 28 April 2017, 17:03:35
[...]Ich habe mal eine Konfiguration basierend auf der NGINX Anleitung im Wiki und deiner Konfiguration für das Thema Websockets als Vorschlag mal im Wiki zusammengetragen.

https://wiki.fhem.de/wiki/Diskussion:HTTPS-Absicherung_%26_Authentifizierung_via_nginx_Webserver

Was meint ihr? Aktuell kann ich noch keine Verbindungsabbrüche beobachten.

Hallo Tobias,

danke, ich habe meine Konfiguration mal mit dieser ersetzt und stelle bisher auch keine Schwierigkeiten fest. Es scheint gut zu funktionieren, vorallem mit dem letzten websocket-patch den Rudi eingespielt hat...
sG
Joe
Titel: Antw:Nginx als Reverse Proxy mit websocket für FHEM
Beitrag von: All-Ex am 02 Mai 2017, 20:45:01
Hallo,

unter Windows (Chrome, Edge, Firefox) funktioniert diese Konfig:
https://wiki.fhem.de/wiki/Diskussion:HTTPS-Absicherung_%26_Authentifizierung_via_nginx_Webserver

Allerdings bei mir mit iOS nicht. Habt ihr das mal mit iOS getestet?

Titel: Antw:Nginx als Reverse Proxy mit websocket für FHEM
Beitrag von: JoeALLb am 23 August 2017, 10:13:30
Zitat von: All-Ex am 02 Mai 2017, 20:45:01
Allerdings bei mir mit iOS nicht. Habt ihr das mal mit iOS getestet?
Gibts hie rmittlerweile eine Verbesserung?
Titel: Antw:Nginx als Reverse Proxy mit websocket für FHEM
Beitrag von: stromer-12 am 08 November 2017, 18:44:48
Bei mir läuft der Proxy, aber ich musste noch folgende Regel einfügen, damit die SVG Grafiken erzeugt werden.

add_header              X-Frame-Options SAMEORIGIN;

Darstellung mit Firefox unter Linux und Android funktionieren.
Titel: Antw:Nginx als Reverse Proxy mit websocket für FHEM
Beitrag von: LR66 am 18 Februar 2018, 18:26:35
Hallo,
ich habe nginx als reverse proxy ähnlich Wiki angelegt und Aufruf vom WAN über den freigeschaltenen Port auf fhemweb funktioniert. Allerdings kommen keine Zustandsänderungen, d.h. nach Bedienung oder um aktuellen Zustand zu sehen, muss ich die Seite aktualisieren. Welcher Teil der conf bzw. welche Befehle beeinflussen die Rückinfo von fhem/den Seitenrefresh? Das "proxy_redirect" (ist bei einigen Beiträgen auskommentiert)? Timeout hochsetzen und buffering off halfen nicht.
Bei mir sind nginx und fhem auf selbem Rechner und ich habe 8443 als listen port mit entsprechender SSL-Verschlüsselung... sowie location /fhem
Geht bei euch die aktuelle Statusanzeige?
Vg Lutz
Titel: Antw:Nginx als Reverse Proxy mit websocket für FHEM
Beitrag von: LR66 am 18 Februar 2018, 18:38:11
Habe für meine 8083 fhemweb-Instanz gerade attr longpoll von websocket auf 1 geändert und damit funktioniert mein nginx proxy so wie gewollt mit Anzeige des aktuellen Status (unter Firefox).
Ist die Änderung von websocket auf 1 ungünstig? Wie bekommt man das mit websocket hin?
Danke, Lutz
Titel: Antw:Nginx als Reverse Proxy mit websocket für FHEM
Beitrag von: CoolTux am 18 Februar 2018, 19:21:09
/etc/nginx/nginx.conf

.........
http {

        ##
        # Basic Settings
        ##

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

        sendfile on;
.....


/etc/nginx/site-enables/ressource

.......
        location / {
                proxy_http_version      1.1;

                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection $connection_upgrade;
..........
Titel: Antw:Nginx als Reverse Proxy mit websocket für FHEM
Beitrag von: LR66 am 19 Februar 2018, 16:20:56
Faszinierend - noch ein neuer Ansatz, danke CoolTux... muss mir meine nginx.conf mal ansehen und das von Dir unten testen.
Gem. Fhem-Wiki und auch sonst sah ich bisher keine Veranlassung an der zentralen nginx.conf was zu ändern oder zu prüfen - habe meinen Reverse Proxy nur als File 'meine.dyndns.domain' unter /sites-available angelegt und nach /sites_enabled gelinkt (dort hab ich alles inkl.  ssl und zum Blocking unerwünschter Länder... drin)
Im Wiki-nginx-reverse-Artikel gibt es eine Bsp. Conf mit auskommentiertem Teil bzgl. websocket:
      # User Sickboy's Erweiterung für verschlüsselte Websocket-Kommunikation (siehe Diskussionsseite)
      # Für normale Benutzer derzeit kommentiert, vom Autor Andremotz noch bisher ungetestet
      #  ... daher derzeit auskommentiert
      # Wird für 'longpoll' benötigt (z.B. bei FTUI)
      #set $my_http_upgrade "";
      #set $my_connection "Connection";

      #if ($http_upgrade = "websocket") {
      #  set $my_http_upgrade $http_upgrade;
      #  set $my_connection "upgrade";
      #}
     
      #proxy_set_header Upgrade $my_http_upgrade;
      #proxy_set_header Connection $my_connection;


Entspricht eher nicht Deinem Ansatz, aber mit dem Unterschied, dass die Änderung nur im File unter sites-available gemacht wird ?

Verständnisfrage:
Läuft so ein Websocket parallel zur HTTP Get/Post-Verbindung als TCP/IP-Verbindung zw. Client und Server (auf gleichem Port) um dem Client neue Events aus fhem mitzuteilen (attr longpoll = websocket)? Anderenfalls - also ohne websocket - fragt das Client-seitige Javascript  wohl aufgrund attr longpoll=1 über HTTP zyklisch beim Server nach, ob sich was geä. hat?
Insofern wär ja der Websocket schon eleganter,schneller und ressourcenschonender...

Eine durchgehende Lösungsbeschreibung für nginx im Wiki wäre hübsch (aber sicher auch schwierig, weil sich Orte nginx, fhem, Lage Zertifikate und weitere Nutzung des nginx für andere Server sich bei den Usern unterscheiden können). Sinnvoll wäre auch im weiteren eine Beschreibung der Einbindung von nginx in fail2ban ... hat das jmd. am laufen und könnte die nötigen Einträge im Wiki ergänzen??? Da müßte man ja einen websocket auch extra behandeln?
Vg, Lutz
Titel: Antw:Nginx als Reverse Proxy mit websocket für FHEM
Beitrag von: CoolTux am 19 Februar 2018, 17:14:57
Es gibt sicherlich viele Wege. Was websocket an sich an geht würde ich Dich gerne an Wikipedia oder im Netz zu findende Referenzen verweisen.
Ich kann Dir nur sagen das es so bei mir funktioniert.
Titel: Antw:Nginx als Reverse Proxy mit websocket für FHEM
Beitrag von: JoeALLb am 19 Februar 2018, 17:30:16
Geht diese Variante auch mit iPhones gut? Meine bisherige hatte dort noch so manche zicken
Titel: Antw:Nginx als Reverse Proxy mit websocket für FHEM
Beitrag von: CoolTux am 19 Februar 2018, 17:33:23
Keine Ahnung, weiß ja nicht was deine Zicken sind.  ;D
Hast du Probleme mit dem longpoll
Titel: Antw:Nginx als Reverse Proxy mit websocket für FHEM
Beitrag von: truckl am 17 März 2018, 14:53:25
Hallo und vielen Dank für die Anleitung und all die Tips zu nginx als Reverse-Proxy für FHEM.

Allerdings hat bei mir die "User Sickboy's"-Erweiterung für longpoll=websocket von der nginx-Wiki-Haupt-Seite(https://wiki.fhem.de/wiki/HTTPS-Absicherung_%26_Authentifizierung_via_nginx_Webserver (https://wiki.fhem.de/wiki/HTTPS-Absicherung_%26_Authentifizierung_via_nginx_Webserver), Stand 2018-03-17) zunächst nicht funktioniert (Raspbian GNU/Linux 9 (stretch), nginx/1.10.3).

Der Grund war letztlich, daß die dort die proxy_pass-Direktiven oberhalb des Blocks für den Connection-Upgrade  (if ($http_upgrade = "websocket")) stehen.

Bei mir hat es sofort funktioniert, sobald ich es so angeordnet hatte:


      # User Sickboy's Erweiterung für verschlüsselte Websocket-Kommunikation (siehe Diskussionsseite)
      # Für normale Benutzer derzeit kommentiert, vom Autor Andremotz noch bisher ungetestet
      #  ... daher derzeit auskommentiert
      # Wird für 'longpoll' benötigt (z.B. bei FTUI)
      set $my_http_upgrade "";
      set $my_connection "Connection";

      if ($http_upgrade = "websocket") {
        set $my_http_upgrade $http_upgrade;
        set $my_connection "upgrade";
      }
     
      proxy_set_header Upgrade $my_http_upgrade;
      proxy_set_header Connection $my_connection;

      # Gehe zu FHEMWEB wenn kein mobiler Browser
      if ($ua_type != "@mobile"){
          proxy_pass          http://localhost:8083;
      }
      # Gehe zu FHEMWEB smallscreen wenn mobiler Browser
      if ($ua_type = "@mobile"){
          proxy_pass          http://localhost:8084;
      }
      proxy_read_timeout  90;
      #proxy_read_timeout  20736000;
      #proxy_buffering     off;


Auf der Anleitung auf der "Diskussions-Seite" (https://wiki.fhem.de/wiki/Diskussion:HTTPS-Absicherung_%26_Authentifizierung_via_nginx_Webserver (https://wiki.fhem.de/wiki/Diskussion:HTTPS-Absicherung_%26_Authentifizierung_via_nginx_Webserver)) ist das noch richtig.
Ich vermute mal, daß das ein Mißgeschick beim Zusammenführen der Mobil-Browser- und der Websocket-Erweiterung war und hoffe, mit dieser Info denjenigen weiterhelfen zu können, die evtl. vor dem gleichen Problem stehen, vor dem ich auch stand.
Titel: Antw:Nginx als Reverse Proxy mit websocket für FHEM
Beitrag von: Karflyer am 04 April 2018, 09:29:34
Hallo zusammen,
eine Frage an die Experten. Ich nutze die hier beschriebene Methode bzw. das im FHEM-WIKI zu diesem Thema veröffentlichte Listing um mit NGINX als Reverse-Proxy auf das FHEM-WEB von 'außen' zuzugreifen. Das funktioniert soweit.
Im WIKI wird allerdings auch propagiert die 'global'-Direktive an den FHEMWEB-Instanzen zu entfernen. Wenn ich das 'global' entferne geht jedoch jede Möglichkeit per Browser auf FHEM zuzugreifen verloren. Weder von außen noch vom Hausnetz aus, ist FHEM erreichbar. Der Browser bzw. NGINX meldet '502 Bad Gateway'.
Der FHEM-Server und der Reverse-Proxy (NGINX) laufen bei mir nicht auf der gleichen Maschine (zwei PI). Hat es etwas damit zu tun? Oder an welchem Rädchen muss ich drehen? Ich bin selbst kein Experte in Sachen Proxy, weshalb ich den Sinn in manchen Direktiven nicht deuten kann. In der Konfigurationsdatei für den Reverse-Proxy steht Eingangs die Direktive 'server_name'. Was genau muss hier eingetragen werden? Der Name des Hosts auf dem der Proxy läuft, der Name des Hosts auf dem FHEM läuft oder der DynDNSName unter dem der Proxy von außen angesprochen wird?
Wäre schön, wenn mir da jemand auf die Sprünge helfen könnte.
Grüße
Stefan
Titel: Antw:Nginx als Reverse Proxy mit websocket für FHEM
Beitrag von: CoolTux am 04 April 2018, 09:43:29
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.
Titel: Antw:Nginx als Reverse Proxy mit websocket für FHEM
Beitrag von: Karflyer am 04 April 2018, 10:41:51
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 (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.
Titel: Antw:Nginx als Reverse Proxy mit websocket für FHEM
Beitrag von: CoolTux am 04 April 2018, 10:46:37
Zitat von: Karflyer am 04 April 2018, 10:41:51
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 (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
Titel: Antw:Nginx als Reverse Proxy mit websocket für FHEM
Beitrag von: Karflyer am 04 April 2018, 11:17:41
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;'
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.
Titel: Antw:Nginx als Reverse Proxy mit websocket für FHEM
Beitrag von: CoolTux am 04 April 2018, 11:20:34
Zitat von: CoolTux am 04 April 2018, 09:43:29
Unter server_name gehört der externe DNS Name, also genau so wie Du FHEM von aussen aufrufen tust.
Titel: Antw:Nginx als Reverse Proxy mit websocket für FHEM
Beitrag von: clickme am 25 April 2018, 19:41:21
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.


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 ;)
Titel: Antw:Nginx als Reverse Proxy mit websocket für FHEM
Beitrag von: Loredo am 06 Juli 2018, 23:19:15
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.
Titel: Antw:Nginx als Reverse Proxy mit websocket für FHEM
Beitrag von: CoolTux am 07 Juli 2018, 06:39:23
Kann man bei iOS wenigstens ein selbst erstelltes rootCA importieren?
Titel: Antw:Nginx als Reverse Proxy mit websocket für FHEM
Beitrag von: Loredo am 07 Juli 2018, 09:35:08
Klar das geht :-)
Titel: Antw:Nginx als Reverse Proxy mit websocket für FHEM
Beitrag von: JoeALLb am 09 Juli 2018, 14:08:46

Zitat von: clickme am 25 April 2018, 19:41:21
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
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
Titel: Antw:Nginx als Reverse Proxy mit websocket für FHEM
Beitrag von: der_oBi am 26 Mai 2019, 14:35:45
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  :(
Titel: Antw:Nginx als Reverse Proxy mit websocket für FHEM
Beitrag von: CoolTux am 26 Mai 2019, 15:12:01
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.


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;
        }
}
Titel: Antw:Nginx als Reverse Proxy mit websocket für FHEM
Beitrag von: hexenmeister am 26 Mai 2019, 18:29:18
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.
Titel: Antw:Nginx als Reverse Proxy mit websocket für FHEM
Beitrag von: Wernieman am 26 Mai 2019, 20:23:59
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....
Titel: Antw:Nginx als Reverse Proxy mit websocket für FHEM
Beitrag von: FunkOdyssey am 26 Mai 2019, 21:06:22
Zitat von: hexenmeister am 26 Mai 2019, 18:29:18
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.
Titel: Antw:Nginx als Reverse Proxy mit websocket für FHEM
Beitrag von: hexenmeister am 26 Mai 2019, 23:02:52
Zitat von: Wernieman am 26 Mai 2019, 20:23:59
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....
Es sind sogar nocth mehr, da sit npoch PHP und Letsencrypt-Bot drin.  ::)
Grundsätzlich gebe ich dir natürlich Recht, aber an dieser Stelle ist das halt recht bequem gelöst. Das sind zwar mehrere Produkte in einem, immerhin lösen sie eine gemeinsame Aufgabe.
Titel: Antw:Nginx als Reverse Proxy mit websocket für FHEM
Beitrag von: hexenmeister am 26 Mai 2019, 23:29:47
Zitat von: FunkOdyssey am 26 Mai 2019, 21:06:22
Gerne ja. Deine Variante würde mich auch interessieren.

Zuerst müssen (wenn nicht bereits geschehen) docker und docker-compose installiert werden.
Die Datei "docker-compose.yml" muss in einem leeren Verzeichniss abgelegt werden.
Weitere Infos zu dem Image und Benutzung: https://github.com/linuxserver/docker-letsencrypt

docker-compose.yml:
version: "2"
services:
  letsencrypt:
    image: linuxserver/letsencrypt
    container_name: letsencrypt
    cap_add:
      - NET_ADMIN
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/Berlin
      - URL=<hier die URL eintragen! Z.B. irgendwas.spdns.org>
      - SUBDOMAINS= #www,
      - VALIDATION=http
      - DNSPLUGIN=cloudflare #optional
      - DUCKDNSTOKEN=<token> #optional
      - EMAIL=<mail adresse> #optional
      - DHLEVEL=2048 #optional, (default=2048, can be set to 1024 or 4096)
      - ONLY_SUBDOMAINS=false #optional
      #- EXTRA_DOMAINS= #<extradomains> #optional
      - STAGING=false #optional
    volumes:
      - ./data/config:/config
    ports:
      - 443:443
      - 80:80   # for redirect to 443
    restart: unless-stopped


In dem Verzeichnis, wo die yml Datei liegt muss noch ein Verzeichniss data/config erstellt werden. Dort sollen nach dem ersten Container-Start ("docker-compose up" in diesem Verzeichnis ausführen) eine Menge Verzeichnisse und Dateien entstehen.
Im Verzeichnis data/config/nginx/proxy-confs existieren dann mehrere Vorlagen für verschiedenen Dienste. Fhem ist zwar nicht dabei, ist aber leicht selbst zu esrstellen. Hier ist meine Version:

    # check user agent
    if ($http_user_agent ~* '(iPhone|iPod|Opera Mini|Android.*Mobile|NetFront|PSP|BlackBerry|Windows Phone)') {
        set $ua_type "@mobile";
    }

   # default
    set $fport "8083";
    set $fmport "8084";
   
    # fhem UI
if ($uri ~ "/fhem.*"){
        set $fport "8083";
        set $fmport "8084";
    }
   
    # fhem test     8983
    if ($uri ~ "/fhem-test.*"){
        set $fport "8983";
        set $fmport "8984";
    }
   
    location / {
        access_log off;
        error_log off;
   
        # Wird fuer 'longpoll' benoetigt (z.B. bei FTUI)
        set $my_http_upgrade "";
        set $my_connection "Connection";
       
        if ($http_upgrade = "websocket") {
          set $my_http_upgrade $http_upgrade;
          set $my_connection "upgrade";
        }
       
        proxy_set_header Upgrade $my_http_upgrade;
        proxy_set_header Connection $my_connection;
       
        auth_basic "Restricted area";
        auth_basic_user_file /config/nginx/.htpasswd;
       
        # enable the next two lines for ldap auth, also customize and enable ldap.conf in the default conf
        #auth_request /auth;
        #error_page 401 =200 /login;

        include /config/nginx/proxy.conf;
        resolver 127.0.0.11 valid=30s;
        set $upstream 192.168.0.15;
        #proxy_pass http://$upstream:8080;
       
        # Gehe zu FHEMWEB wenn kein mobiler Browser
        if ($ua_type != "@mobile"){
            #proxy_pass http://$upstream:8083;
            proxy_pass http://$upstream:$fport;
        }
       
        # Gehe zu FHEMWEB smallscreen wenn mobiler Browser
        if ($ua_type = "@mobile"){
            #proxy_pass http://$upstream:8084;
            proxy_pass http://$upstream:$fmport;
        }
    }



.../config/nginx/.htpasswd muss nattürlich auch noch erstellt werden.

Titel: Antw:Nginx als Reverse Proxy mit websocket für FHEM
Beitrag von: der_oBi am 27 Mai 2019, 14:47:58
Zitat von: CoolTux am 26 Mai 2019, 15:12:01
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.

Das hat leider auch nicht funktioniert. Sobald ich meine FHEMWEB-Instanz auf longpoll "Websocket" umstelle bekomme ich Disconnect-Meldungen am laufenden Band. Mit longpoll "1" ist alles prima...
Ich würde ja gerne mal debuggen, weiß aber garnicht, wo ich überhaupt hinschauen soll (FHEMWEB, nginx, ... ?). Hat jemand einen Tipp wo ich hinschauen sollte?

@hexenmeister: Ist natürlich auch eine interessante Herangehensweise. Aber zumindest die nginx-Konfiguration ist ja die gleiche, wie bspw. im Wiki beschrieben. Und die funktioniert bei mir ja leider nicht :-(
Titel: Antw:Nginx als Reverse Proxy mit websocket für FHEM
Beitrag von: der_oBi am 28 Mai 2019, 19:21:46
Habe mal die JavaScript Konsole meines Safari bemüht und folgendes Ergebnis erhalten:

[Log] 19:15:52.401 FW_queryValue:{AttrVal("EDL21_Stromzaehler","room","")} (fhemweb.js, line 500)
[Log] 19:15:52.494 Inform-channel opened (websocket) with filter EDL21_Stromzaehler (fhemweb.js, line 500)
[Error] WebSocket connection to 'wss://192.168.0.31/fhem?XHR=1&inform=type=status;filter=EDL21_Stromzaehler;since=1559063751;fmt=JSON&fw_id=2152&timestamp=1559063752494' failed: Unexpected response code: 401
[Log] 19:15:52.516 ERRMSG:Connection lost, trying a reconnect every 5 seconds.< (fhemweb.js, line 500)
[Log] 19:15:57.417 ERRMSG:< (fhemweb.js, line 500)
[Log] 19:15:57.519 Inform-channel opened (websocket) with filter EDL21_Stromzaehler (fhemweb.js, line 500)
[Error] WebSocket connection to 'wss://192.168.0.31/fhem?XHR=1&inform=type=status;filter=EDL21_Stromzaehler;since=1559063751;fmt=JSON&fw_id=2152&timestamp=1559063757519' failed: Unexpected response code: 401
[Log] 19:15:57.543 ERRMSG:Connection lost, trying a reconnect every 5 seconds.< (fhemweb.js, line 500)
[Log] 19:16:02.444 ERRMSG:< (fhemweb.js, line 500)


Kann jemand etwas damit anfangen und erkennt wo mein Problem liegt?
Wenn ich ohne Umwege über nginx zugreife, sehe ich natürlich keinerlei Fehlermeldungen.
Titel: Antw:Nginx als Reverse Proxy mit websocket für FHEM
Beitrag von: der_oBi am 28 Mai 2019, 20:19:20
Alles klar, Fehler gefunden.
Das entscheidende Wort in meinem letzten Post lautete "Safari". Mit aktiviertem basicAuth (egal ob über ein allowed-Device oder über nginx) kann mit Safari keine Websocket-Verbindung hergestellt werden. Ist ja mal wieder erbärmlich von der Apfel-Crew :-(

Getestet mit: Safari 12.1.1 auf macOS 10.14.5

Dann werde ich mir wohl mit longpoll = 1 auf meinen Apfelgeräten behelfen müssen...Für iOS gilt ja leider das gleiche. Gott sei Dank trägt alles in unserem Haus einen Apfel ;-)
Titel: Antw:Nginx als Reverse Proxy mit websocket für FHEM
Beitrag von: JoeALLb am 29 Mai 2019, 08:34:53
Oder Client-Zertifikate als Autentifizierung....
Titel: Antw:Nginx als Reverse Proxy mit websocket für FHEM
Beitrag von: rudolfkoenig am 29 Mai 2019, 09:11:56
ZitatMit aktiviertem basicAuth (egal ob über ein allowed-Device oder über nginx) kann mit Safari keine Websocket-Verbindung hergestellt werden.
Das war vor etwa einem Jahr schon so, danke fuer die Bestaetigung, dass die aktuelle Safari Version das nicht gefixt hat.
Titel: Antw:Nginx als Reverse Proxy mit websocket für FHEM
Beitrag von: der_oBi am 29 Mai 2019, 11:20:36
Ähm, genau. Ich wollte eigentlich noch den Link zum entsprechenden Post einfügen, der die Erleuchtung gebracht hat ;-)

https://forum.fhem.de/index.php/topic,88996.0.html (https://forum.fhem.de/index.php/topic,88996.0.html)

Zitat von: JoeALLb am 29 Mai 2019, 08:34:53
Oder Client-Zertifikate als Autentifizierung....
Kannst Du das genauer erläutern bzw. einen Link nennen?
Titel: Antw:Nginx als Reverse Proxy mit websocket für FHEM
Beitrag von: JoeALLb am 29 Mai 2019, 11:37:44
Beispielsweise sowas.
https://fardog.io/blog/2017/12/30/client-side-certificate-authentication-with-nginx/
Hab grad nicht genug zeit, einen besseren Link zu googeln, hab es bei mir ohne howto gemacht.

sG
Joe
Titel: Antw:Nginx als Reverse Proxy mit websocket für FHEM
Beitrag von: FunkOdyssey am 29 Mai 2019, 12:34:18
Soweit ich in Erinnerung habe, wird das aber nicht für LetsEncrypt-Zertifikate möglich sein.
Titel: Antw:Nginx als Reverse Proxy mit websocket für FHEM
Beitrag von: JoeALLb am 29 Mai 2019, 12:39:21
Das hat damit nix zu tun. Siehst du in dem link etwas vonwegen offiziellem Zertifikat? Https Verschlüsselung und Client Verschlüsselung können mit separaten Zertifikaten benutzt werden. Meist nimmt an für letzteres eigens erstellte.
Titel: Antw:Nginx als Reverse Proxy mit websocket für FHEM
Beitrag von: FunkOdyssey am 29 Mai 2019, 12:57:43
Ich verfolge gerade mehrere Nginx-Threads. In einem ging es um LetsEncrypt. Ich habe die Threads wohl verwechselt.
Titel: Antw:Nginx als Reverse Proxy mit websocket für FHEM
Beitrag von: All-Ex am 09 September 2019, 10:16:28
Hallo zusammen,

im Web habe ich einen Ansatz gefunden, wie Websocket mit nginx (bzw. openresty) als Reverse Proxy, Letsencrypt-SSL-Zertifikaten und zertifikatsbasierter Authentisierung auch mit Safari (iOS) funktionieren könnte:
https://blog.christophermullins.com/2017/04/30/securing-homeassistant-with-client-certificates/

Was haltet ihr davon?

Viele Grüße,
Alex
Titel: Antw:Nginx als Reverse Proxy mit websocket für FHEM
Beitrag von: ebeneezer am 07 Oktober 2019, 15:13:27
Bei den ganzen Strömungen in diesem Thread muss ich jetzt fragen:

FHEM, Reverse Proxy nginX mit Server-Trust Zertifikaten sowie Client Zertifikat-Authentifizierung ist mit Safari (macos oder iOS) als Client nicht möglich, weil Safari während eines Longpoll Handshakes keine oder falsche Zertifikate präsentiert. Ist das richtig?

Ich bestätige im übrigen, dass das oben beschriebene Setup unter Nutzung der Config aus diesem Thread mit Chrome als Client problemlos funktioniert: websocket und logpoll

Mit bestem Dank vorab für eine Klarstellung.

Titel: Antw:Nginx als Reverse Proxy mit websocket für FHEM
Beitrag von: Wernieman am 07 Oktober 2019, 15:14:59
Eigentlich sollte es auch mit safarie funktionieren ... oder Apple macht wirklich "was eigenes "

Edit: es bezog sich auf die Aussage von ebeneezer

Bei dem Link von All-Ex:
Warum dort ein LUA-Script für Proxy-Aufgaben verwendet werden ist mir ein Rätsel ....
Titel: Antw:Nginx als Reverse Proxy mit websocket für FHEM
Beitrag von: ebeneezer am 07 Oktober 2019, 15:19:56
Gut zu hören - wer hat das mit Safari am laufen und zeigt mal seine nginX Config?
Titel: Antw:Nginx als Reverse Proxy mit websocket für FHEM
Beitrag von: 9zehn75 am 25 November 2019, 15:09:52
Ich würde das gerne nochmals hochholen: hat irgendwer eine nginx-Config, die als reverse proxy auch mit iOS-Safari funktioniert?
Titel: Antw:Nginx als Reverse Proxy mit websocket für FHEM
Beitrag von: Loredo am 28 Dezember 2019, 16:34:05
Safari funktioniert nur richtig, wenn die Webseite, die Websockets benutzt, ein valides SSL Zertifikat verwendet. So eines musst du wahrscheinlich bei dir installieren und FHEM dann auch über die korrekte URL aufrufen. Geht natürlich auch mit einer eigenen privaten CA.
Titel: Antw:Nginx als Reverse Proxy mit websocket für FHEM
Beitrag von: dickdickerson am 25 Januar 2020, 14:48:41
Ich habe ähnliche Probleme (daher schreibe ich es hier rein), allerdings über HAproxy(2.1.2-alpine) als ReverseProxy. Mir ist das "Connection lost, trying a reconnect every 5 seconds." schon des öftern aufgefallen und jetzt habe ich mich mal dran gemacht das Problem zu analysieren.

Mein Aufbau sieht aktuell so aus:
Extern --> HAproxy (https:443) --> FHEM (http:8083)
alternativ auch folgendes getestet:
Extern --> HAproxy (https:443) --> FHEM (https:8084 selfsigned)

Ich habe ein gültiges Letsencrypt-Zertifikat am Frontend.

Bei mir tritt das Problem mit "attr WEBrproxy longpoll websocket" auf.

Chromium zeigt folgenden Fehler an:
WebSocket connection to 'wss://<domain>/fhem/dashboard/Dashboard?XHR=1&inform=type=status;filter=.*;since=1579958874;fmt=JSON&fw_id=1445&timestamp=1579958882521' failed: Error during WebSocket handshake: Incorrect 'Sec-WebSocket-Accept' header value
FW_longpoll @ fhemweb.js:1208


In besagter Zeile 1208 in fhemweb.js steht folgendes:
1207  if(typeof WebSocket == "function" && FW_longpollType == "websocket") {
1208    FW_pollConn = new WebSocket(loc.replace(/[#&?].*/,'')
1209                                   .replace(/^http/i, "ws")+query);
1210    FW_pollConn.onclose =
1211    FW_pollConn.onerror =
1212    FW_pollConn.onmessage = FW_doUpdate;
1213
1214  }


Meine backend-Konfig in HAproxy:
backend fhem
        acl forwarded_proto hdr_cnt(X-Forwarded-Proto) eq 0
        acl forwarded_port hdr_cnt(X-Forwarded-Port) eq 0
        option httpchk GET /fhem
        http-check expect status 200
        http-response set-header Strict-Transport-Security max-age=31536000;\ includeSubDomains
        #http-response set-header X-Frame-Options SAMEORIGIN
        #http-response set-header X-XSS-Protection 1;\ mode=block
        #http-response set-header X-Content-Type-Options nosniff
        #http-response set-header Feature-Policy \'none\'
        #http-response set-header Referrer-Policy no-referrer
        #http-response set-header Content-Type text/html;\ charset=UTF-8
        http-response del-header Server
        acl AuthOkay_FHEM http_auth(FHEM)
        timeout client 25s
        timeout connect 5s
        timeout server 25s
        timeout tunnel 1h
        timeout http-keep-alive 1s
        timeout http-request 15s
        timeout queue 30s
        timeout tarpit 60s
        #timeout client-fin 10s
        http-request auth realm FHEM if !AuthOkay_FHEM
        http-request add-header X-Forwarded-Port %[dst_port] if forwarded_port
        http-request add-header X-Forwarded-Proto https if { ssl_fc } forwarded_proto
        mode http
        server fhem <ip-fhem>:8084 ssl verify none check inter 60000 rise 6 fall 12
        #server fhem <ip-fhem>:8083 check inter 60000 rise 6 fall 12


So wie ich das sehe (zumindest zeigt mir der Browser es nicht an), kommt am Browser der Header 'Sec-WebSocket-Accept' nicht mehr an.
Ich habe schon mit tcpdump einen Dump auf dem Server wo HAproxy läuft gemacht, mit "tcpdump -nw host <ip-fhem> and '(port 8083 or 8084)'".
In dem Dump sehe ich, dass ein GET vom HAproxy zu FHEM gesendet wird und FHEM mit "HTTP/1.1 101 Switching Protocols" antwortet:

Request:
Frame 4: 843 bytes on wire (6744 bits), 843 bytes captured (6744 bits)
Raw packet data
Internet Protocol Version 4, Src: <haproxyip>, Dst: <fhemip>
Transmission Control Protocol, Src Port: 32996, Dst Port: 8083, Seq: 1, Ack: 1, Len: 791
Hypertext Transfer Protocol
    GET /fhem?XHR=1&inform=type=status;filter=;since=1579956273;fmt=JSON&fw_id=600&timestamp=1579956446194 HTTP/1.1\r\n
    host: <domain>\r\n
    connection: Upgrade\r\n
    pragma: no-cache\r\n
    cache-control: no-cache\r\n
    authorization: Basic <basicauth>\r\n
    user-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/79.0.3945.79 Chrome/79.0.3945.79 Safari/537.36\r\n
    upgrade: websocket\r\n
    origin: https://<domain>\r\n
    sec-websocket-version: 13\r\n
    accept-encoding: gzip, deflate, br\r\n
    accept-language: de-DE,de;q=0.9,en-US;q=0.8,en;q=0.7\r\n
    sec-websocket-key: tV5arw6WE10arEuOYdX27A==\r\n
    sec-websocket-extensions: permessage-deflate; client_max_window_bits\r\n
    x-forwarded-port: 443\r\n
    x-forwarded-proto: https\r\n
    x-forwarded-for: ::ffff:<externalip>\r\n
    \r\n
    [Full request URI: http://<domain>/fhem?XHR=1&inform=type=status;filter=;since=1579956273;fmt=JSON&fw_id=600&timestamp=1579956446194]
    [HTTP request 1/1]
    [Response in frame: 6]


Response:
Frame 6: 223 bytes on wire (1784 bits), 223 bytes captured (1784 bits)
Raw packet data
Internet Protocol Version 4, Src: <fhemip>, Dst: <haproxyip>
Transmission Control Protocol, Src Port: 8083, Dst Port: 32996, Seq: 1, Ack: 792, Len: 171
Hypertext Transfer Protocol
    HTTP/1.1 101 Switching Protocols\r\n
    Upgrade: websocket\r\n
    Connection: Upgrade\r\n
    Sec-WebSocket-Accept:Kfh9QIsMVZcl6xEPYxPHzW8SZ8w=\r\n
    X-FHEM-csrfToken: csrf_114925038332728e15\r\n
    \r\n
    [HTTP response 1/1]
    [Time since request: 0.018372000 seconds]
    [Request in frame: 4]
    [Request URI: http://<domain>/fhem?XHR=1&inform=type=status;filter=;since=1579956273;fmt=JSON&fw_id=600&timestamp=1579956446194]


Der Response scheint sich aber in Luft aufzulösen.
Ich habe andere Subdomains (Nextcloud mit Collabora) bei denen Websocket ohne Probleme funktioniert und die HAproxy-Konfig identisch ist.
Laut der Doku (https://www.haproxy.com/de/blog/websockets-load-balancing-with-haproxy/) sind meine Konfigzeilen ausreichend (Funktioniert ja auch bei Nextcloud).

Hat irgendjemand noch einen Tipp was das Problem sein könnte? Mir gehen die Ideen aus.


Edit:
Ich habe gerade mal kontrolliert, was mir die Developer-Tools von Firefox sagen. Der Response-Header wird offenbar doch zurück zum Browser gesendet. In Firefox sehe ich nämlich den Response.
Auf Github habe ich ein Issue gefunden, wo der Ersteller genau das selbe Problem mit FHEM hat, jedoch mit Traefik. (https://github.com/containous/traefik/issues/5330 (https://github.com/containous/traefik/issues/5330))
Dort ist es offenbar ein Groß/Kleinschreib-Problem vom Response-Header Sec-WebSocket-Accept selbst.

Also habe ich das mal nachgestellt:

Mit ReverseProxy:
Request:
Sec-WebSocket-Key: WhkUkJc32AK1r5P7qWsDrA==
Response:
sec-websocket-accept: Kfh9QIsMVZcl6xEPYxPHzW8SZ8w=

Ohne ReverseProxy:
Request:
Sec-WebSocket-Key: y3yVaexowsFIYghS0OiZtg==
Response:
Sec-WebSocket-Accept: OdkJmc2/FPCa4dIR7ilp3d+fHBY=

Hier ist zu sehen, dass bei der Verbindung über den HAproxy der Response-Header in Kleinbuchstaben geschrieben ist.
Laut dem Issue auf Github (https://github.com/containous/traefik/pull/5397/files/43f1c0ba380ca527c645f5067f69da1965e02e6c (https://github.com/containous/traefik/pull/5397/files/43f1c0ba380ca527c645f5067f69da1965e02e6c)) sollten die Header laut RFC eigentlich case-insensitiv sein.

Ich versuche jetzt mal mit HAproxy den Header zu korrigieren. Mal schauen ob das klappt.
Titel: Antw:Nginx als Reverse Proxy mit websocket für FHEM
Beitrag von: P.A.Trick am 01 Februar 2020, 17:31:55
Zitat von: hexenmeister am 26 Mai 2019, 23:29:47
Zuerst müssen (wenn nicht bereits geschehen) docker und docker-compose installiert werden.
Die Datei "docker-compose.yml" muss in einem leeren Verzeichniss abgelegt werden.
Weitere Infos zu dem Image und Benutzung: https://github.com/linuxserver/docker-letsencrypt

docker-compose.yml:
version: "2"
services:
  letsencrypt:
    image: linuxserver/letsencrypt
    container_name: letsencrypt
    cap_add:
      - NET_ADMIN
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/Berlin
      - URL=<hier die URL eintragen! Z.B. irgendwas.spdns.org>
      - SUBDOMAINS= #www,
      - VALIDATION=http
      - DNSPLUGIN=cloudflare #optional
      - DUCKDNSTOKEN=<token> #optional
      - EMAIL=<mail adresse> #optional
      - DHLEVEL=2048 #optional, (default=2048, can be set to 1024 or 4096)
      - ONLY_SUBDOMAINS=false #optional
      #- EXTRA_DOMAINS= #<extradomains> #optional
      - STAGING=false #optional
    volumes:
      - ./data/config:/config
    ports:
      - 443:443
      - 80:80   # for redirect to 443
    restart: unless-stopped


In dem Verzeichnis, wo die yml Datei liegt muss noch ein Verzeichniss data/config erstellt werden. Dort sollen nach dem ersten Container-Start ("docker-compose up" in diesem Verzeichnis ausführen) eine Menge Verzeichnisse und Dateien entstehen.
Im Verzeichnis data/config/nginx/proxy-confs existieren dann mehrere Vorlagen für verschiedenen Dienste. Fhem ist zwar nicht dabei, ist aber leicht selbst zu esrstellen. Hier ist meine Version:

    # check user agent
    if ($http_user_agent ~* '(iPhone|iPod|Opera Mini|Android.*Mobile|NetFront|PSP|BlackBerry|Windows Phone)') {
        set $ua_type "@mobile";
    }

   # default
    set $fport "8083";
    set $fmport "8084";
   
    # fhem UI
if ($uri ~ "/fhem.*"){
        set $fport "8083";
        set $fmport "8084";
    }
   
    # fhem test     8983
    if ($uri ~ "/fhem-test.*"){
        set $fport "8983";
        set $fmport "8984";
    }
   
    location / {
        access_log off;
        error_log off;
   
        # Wird fuer 'longpoll' benoetigt (z.B. bei FTUI)
        set $my_http_upgrade "";
        set $my_connection "Connection";
       
        if ($http_upgrade = "websocket") {
          set $my_http_upgrade $http_upgrade;
          set $my_connection "upgrade";
        }
       
        proxy_set_header Upgrade $my_http_upgrade;
        proxy_set_header Connection $my_connection;
       
        auth_basic "Restricted area";
        auth_basic_user_file /config/nginx/.htpasswd;
       
        # enable the next two lines for ldap auth, also customize and enable ldap.conf in the default conf
        #auth_request /auth;
        #error_page 401 =200 /login;

        include /config/nginx/proxy.conf;
        resolver 127.0.0.11 valid=30s;
        set $upstream 192.168.0.15;
        #proxy_pass http://$upstream:8080;
       
        # Gehe zu FHEMWEB wenn kein mobiler Browser
        if ($ua_type != "@mobile"){
            #proxy_pass http://$upstream:8083;
            proxy_pass http://$upstream:$fport;
        }
       
        # Gehe zu FHEMWEB smallscreen wenn mobiler Browser
        if ($ua_type = "@mobile"){
            #proxy_pass http://$upstream:8084;
            proxy_pass http://$upstream:$fmport;
        }
    }



.../config/nginx/.htpasswd muss nattürlich auch noch erstellt werden.

Hexenmeister geht das auch ohne eine valide Web Adresse, also mit localhost?