Nginx als Reverse Proxy mit websocket für FHEM

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

Vorheriges Thema - Nächstes Thema

hexenmeister

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.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

hexenmeister

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.

Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

der_oBi

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 :-(

der_oBi

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.

der_oBi

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 ;-)

JoeALLb

Oder Client-Zertifikate als Autentifizierung....
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

rudolfkoenig

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.

der_oBi

Ä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

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?

JoeALLb

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
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

FunkOdyssey

Soweit ich in Erinnerung habe, wird das aber nicht für LetsEncrypt-Zertifikate möglich sein.

JoeALLb

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

FunkOdyssey

Ich verfolge gerade mehrere Nginx-Threads. In einem ging es um LetsEncrypt. Ich habe die Threads wohl verwechselt.

All-Ex

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

ebeneezer

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.


Wernieman

#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 ....
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html