fronthem und Reverse Proxy

[Kai-Alfonso]

Hi,

ist es eigentlich mittlerweile möglich, Smartvisu mit fronthem hinter einem reverse proxy zu betreiben, um sich ein wenig der Last des VPN zu entledigen? Dachte da an Client Zertifikate oder ähnliches. Das wäre euch erst der zweite Schritt. Der erste wäre das erstmal so zum laufen zu bekommen. Smartvisu lädt, bekommt aber keine Daten von fronthem. Abgelehnte Devices sehe ich auch nicht. Reagiert fronthem nur auf lokale Class C SubNetze?

[Kai-Alfonso]

Hmm, anscheinend zu exotisch die Frage, zu wenig Infos oder nicht interessant?

Hat denn sowas niemand gemacht? Über die Suche finde ich auch nur einen Beitrag ohne Antworten.

Chrome meldet in der Console

Code Auswählen Erweitern

io_fhem.js:296 WebSocket connection to 'wss://192.168.1.30:2121/ws/' failed: Error in connection establishment: net::ERR_CONNECTION_CLOSED

Ich nutze nginx als Reverse Proxy und Websockets sind auch aktiviert

Code Auswählen Erweitern

       proxy_set_header        Upgrade            $http_upgrade;

        proxy_set_header        Connection            $connection_upgrade;

[GammaTwin]

Grüße,

ich hatte das mal testweise mit "traefik" (anstatt nginx) umgesetzt. Wäre das auch eine Option?

[Kai-Alfonso]

Grüße,

ich hatte das mal testweise mit "traefik" (anstatt nginx) umgesetzt. Wäre das auch eine Option?

Ich muss zugeben, das ich traefik nicht kannte. Kling interessant und würde er gerne mal probieren. Ich lad mir mal den Docker Container und dann schaue ich mal. Hast Du ein Howto/Config-File oder ähnliches, wie du das eingerichtet hattest?

[GammaTwin]

Wie fangen wir den da an? Vielleicht am Ende, d.h. die Konfiguration von traefik und der smartVISU.

Ich hoffe, Du hast traefik am laufen, im Docker und die statische Grundkonfiguration (Zugänge, Zertifikate, den Verweis auf die dynamischen Konfigurationen). Ich nutze für die dynamische Konfiguration yml-Dateien.

Und die smartVISU.yml sieht dann so aus:

Code Auswählen Erweitern

#smartVISU inkl websocket
http:
  routers:
    smartVISU:
      entryPoints:
        - web-secure
      middlewares:
        - auth-FHEM
        #- websocket-smartVISU
      rule: "Host(`<dyndns>`) && PathPrefix(`/smartVISU`)"
      service: smartVISU
      priority: 10
      tls:
        certResolver: LetsEncprypt
    websocket:
      entryPoints:
        - web-secure
      middlewares:
        - auth-FHEM
      rule: "Host(`<dyndns>`) && PathPrefix(`/websocket`)"
      service: websocket
      priority: 10
      tls:
        certResolver: LetsEncprypt

  services:
    smartVISU:
      loadBalancer:
        servers:
          - url: http://<interne-IP-smartVISU>
    websocket:
      loadBalancer:
        servers:
          - url: http://<interne-IP-FHEM>:2121

  middlewares:
    #Password
    auth-FHEM:
      basicAuth:
        usersFile: "/etc/traefik/dyn/htpasswd"
        realm: "smartHome"
Erklärung:
- Du erreichst Deine smartVISU über "<dyndns>/smartVISU" (casesensitiv)
- web-secure: ist in der statischen Konfiguration der https-Zugang
- <dyndns> Deine externe Adresse
- <interne-IP-smartVISU> die interne IP Deines Webserver, auf dem smartVISU läuft
- <interne-IP-FHEM> die interne IP des Host auf dem FHEM läuft (Port 2121 ist ja der Standardport)
- auth-FHEM: schaust Du unter traefik unter middlewares "basicAuth" - regelt das Passwort

So dann noch smartVISU konfigurieren:
Leider ist mir nicht gelungen, die Einstellung "Proxy Server" zu verwenden. Ich habe die Einstellung in "Datenverbindung / Treiber" benutzt. Letzlich sieht die config.ini dann so aus:

Code Auswählen Erweitern

driver = "fhem"
driver_address = "<dyndns>/websocket"
driver_port = "443"

Ich nutze traefik sozusagen 2x:
Zuerst zum Umleiten der externen Anfrage auf den internen Server. Dabei wird auch von https auf http gewechselt.
Zum Zweiten wird dann über "Datenverbindung / Treiber" wieder über extern auf intern zum websocket umgeleitet. Auch dabei wird von https auf http gewechselt.

Da bin ich mal gespannt 
Gern auch Meinungen von echten Experten 

[Kai-Alfonso]

Hey. Danke für die Infos. Morgen hab ich Zeit, da schau ich mir das genauer an und gib die Rückmeldung

[Kai-Alfonso]

Hey, kurze Rückmeldung

Da ich noch andere interne Dienste hinterm Nginx hatte, musste ich die erstmal nach Traefik portieren.

Danach habe ich mich an Smartvisu gewagt und hat auch funktioniert, auch wenn ich nicht genau die Einstellungen in der config.ini verstehe.

Vielen Dank dafür.

[GammaTwin]

Schön, dass es auf Anhieb funktioniert hat.

Da Du schreibst, dass Du die config.ini nicht genau verstehst, wollte ich Die die unschöne Seite dieser Konfiguration erklären.

Die Konfiguration funktioniert, weil der websocket durch traefik mit http angesprochen wird. traefik selbst sprichst Du von extern aber mit https an. Daurch ist Konfigartion so einfach.
Nun zur unschönen Seite: Wenn Du Deine smartVISU von intern ansprichst, wird der websocket trotzdem übers Internet angefragt. Wenn die BasicAuth abgelaufen ist, erfolgt dann eine Passwortabfrage. Und das ist ziemlich doof.

Hier wäre ich an einer Lösung interessiert 

[Kai-Alfonso]

Schön, dass es auf Anhieb funktioniert hat.

Da Du schreibst, dass Du die config.ini nicht genau verstehst, wollte ich Die die unschöne Seite dieser Konfiguration erklären.

Die Konfiguration funktioniert, weil der websocket durch traefik mit http angesprochen wird. traefik selbst sprichst Du von extern aber mit https an. Daurch ist Konfigartion so einfach.
Nun zur unschönen Seite: Wenn Du Deine smartVISU von intern ansprichst, wird der websocket trotzdem übers Internet angefragt. Wenn die BasicAuth abgelaufen ist, erfolgt dann eine Passwortabfrage. Und das ist ziemlich doof.

Hier wäre ich an einer Lösung interessiert 

Ich wollte eher eigentlich nicht basicAuth nutzen sondern TLS Client Authentication. Wollte ich eigentlich schon implementiert haben, aber gestern hatte ich noch ein Problem mit dem Websocket, welches ich nicht gefunden habe, was sich aber über nicht selbe repariert hat *lol*



Noch mal vielen dank für deine Config - das hätte ich auf Anhieb erst mal nicht so hinbekommen, weil ich auch nicht ganz den Datenstrom verstehe, aber du hast es mir ja schon ein wenig erklärt. danke dafür

[Kai-Alfonso]

Ich weiß nicht, ob es Dir bei Deinem Problem hilft, aber wenn Du intern die IP auf deinen Dnydns lokal auf eine Private IP auflöst statt den ProviderDNS zu befragen (entweder mit Hosts Datei oder lokalem Resolver), dann sollte der Traffic doch nicht extern gehen, oder?

Und dann die Basic Auth für lokale Netze ausschließen - soll wohl laut diesem Link mit Traefik gehen --> https://community.containo.us/t/traefik-v2-simple-trick-to-bypass-basic-auth/2012

Hatte ich gestern zufällig gefunden, aber noch nicht getestet

[rubinho]

Servus,

ich muss das Thema leider nochmal ausgraben.

Ich betreibe Smartvisu in einem Dockercontainer auf der gleichen Maschine wie Fhem, das nativ läuft.
Um in den Genuss von https zu kommen und keine Portangabe mit dabei zu schreiben, habe ich Smartvisu in Traefik eingebunden (Fhem im Übrigen auch).
Das funktioniert soweit , auch die Websocket Verbindung, allerdings hat die Reverseproxylösung ein Nachteil.
Alle Anfragen auf Smartvisu bzw. alle Websocket Verbindungen kommen immer mit der gleichen Quell IP (Interne Docker IP von Traefik) bei Fronthem an. Das hat zur Folge, dass wenn ich einen Client (z.B. Smartphone) schließe und ich eine weitere Websocketverbindung offen habe, diese mitgeschlossen wird.

Somit habe ich keine Livedaten mehr. Ich müsste dann einmal die Seite aktualisieren, damit die Verbindung wieder aufgebaut wird.

Hat jemand das gleiche Problem festgestellt und eine Lösung dafür?

Viele Grüße
Rubinho

[herrmannj]

auch wenns weh tut: geht nicht. Ich entwickle fronthem auch nicht weiter - daher von meiner Seite keine Änderung in Sicht. Bedaure

[rubinho]

auch wenns weh tut: geht nicht.

Naja, weh tut was anderes.

Ich will Fhem eigentlich weiterhin treu bleiben, da ich die Portierung zu Alternativen und die damit verbundene Arbeit scheue (Das tut weh )
Leider skaliert bzw. performt die UI von Fhem nicht so wie ich mir das vorstelle. Mal von der von der altbacken wirkenden Oberfläche abgesehen.
Da ich aber im Prinzip die gleiche Philosophie (Bei einer guten Automation braucht man keine UI) von Fhem verfolge, habe ich nicht die größten Ansprüche an eine UI.
Lediglich flott sollte sie sein und da ist mittlerweile der Knackpunkt bei Fhem.

Von daher hatte ich mich endlich überwunden es mit Smartvisu zu probieren.
Stand jetzt, ist es lediglich nur ein kosmetisches Problem mit dem Websocket. Wenn du allerdings sagst, dass du die Schnittstelle nicht mehr weiterentwickelst, (Was ich durchaus verstehen kann und respektiere) stelle ich mein Vorhaben jedoch in Frage.

Viele Grüße
Rubinho

[wvhn]

Das Problem ist wahrscheinlich, dass die noch aktiven smartVISU Clients es nicht mitbekommen, wenn der Websocket geschlossen wird. Der fhem-Treiber von smartVISU hat eine Reconnect-Funktion, welche die Verbindung sonst sofort wieder öffnen würde.

Zudem ist mir noch nicht klar, warum die Verbindung beendet wird, wenn nur ein Client geschlossen wird. In Verbindung mit anderen Backends sehen wir eher, dass beim Schließen von Browser-Tabs kein eindeutiges Kommando zum Beenden der Websocket-Verbindung gesendet wird.

Beides müsste doch im Reverse Proxy durch entsprechende Konfiguration abzufangen sein.

Gruß
Wolfram

[rubinho]

Ich sage nur Lebenszeit

Habe die Verbindung nun wieder auf unverschlüsselt (Weiterhin über Traefik) umgestellt und somit wird wieder eine direkte Websocket Verbindung vom Client in Richtung Fhem aufgebaut.
In meinem eigenen LAN hab ich keine Probleme damit und wenn ich außer Haus gehe, springt mein Wireguard Tunnel direkt an. Von daher nicht Perfekt, aber ich habe mehr Lebenszeit.

Trotzdem Danke

VG
Rubinho