Nginx als Reverse Proxy mit websocket für FHEM

Begonnen von h3llsp4wn, 16 Februar 2017, 14:37:53

Vorheriges Thema - Nächstes Thema

flocki

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

fiedel

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.  :)

FeatureLevel: 6.1 auf Wyse N03D ; Deb. 11 ; Perl: v5.14.2 ; IO: HM-MOD-RPI-PCB + VCCU|CUL 868 V 1.66|LinkUSBi |TEK603
HM: SEC-SCO|SCI-3-FM|LC-SW4-PCB|ES-PMSW1-PL|RC-4-2|SEN-MDIR-O|SEC-WDS-2
CUL: HMS100TF|FS20 S4A-2 ; OWDevice: DS18S20|DS2401|DS2406|DS2423

JoeALLb

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
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

All-Ex

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?


JoeALLb

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?
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

stromer-12

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.
FHEM (SVN) auf RPi1B mit HMser | ESPLink
FHEM (SVN) virtuell mit HMLAN | HMUSB | CUL

LR66

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

LR66

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

CoolTux

/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;
..........
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

LR66

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

CoolTux

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.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

JoeALLb

Geht diese Variante auch mit iPhones gut? Meine bisherige hatte dort noch so manche zicken
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

CoolTux

Keine Ahnung, weiß ja nicht was deine Zicken sind.  ;D
Hast du Probleme mit dem longpoll
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

truckl

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, 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) 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.

Karflyer

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