Reverse Proxy

[malte]

patrickgoll : gibt es von dir eine Erfolgsmeldung? Läuft das so?

[thoms3n]

Danke kaiwerner!

Die Anleitung funktionier so. Die Schritte nochmals zusammengefasst:
- nginx mit PHP Support installieren
- eine vhost config anlegen wie von kaiwerner beschrieben mit dem wichtigen Teil "if ($http_upgrade = websocket ...."
- in der smartvisu den config_driver_port auf 443 ändern
- wenn nicht der develop branch verwendet wird dann in io_smarthome.py.js und io_smarthome.py.min.js "ws://" durch "wss://" ersetzten


Und schon hat man nur noch von localhost Verbindungen auf Port 2424

netstat -a | grep 2424
tcp 0 0 *:2424 *:* LISTEN
tcp 0 0 localhost:2424 localhost:53796 VERBUNDEN
tcp 0 0 localhost:53796 localhost:2424 VERBUNDEN

[patrickgoll]

Ja das sieht sehr gut aus! Ich kam leider nicht dazu. Das System auf dem das lief bislang ist mir abgeschmiert und ich muss es erst neu aufsetzen. Dann werde ich das aber auch entsprechend testen. Danke vorab auf jeden Fall schonmal fürs Testen thoms3n

[malte]

Funktioniert tatsächlich! Sehr cool!

Probleme habe ich "nur" bei iOS. Egal welcher Browser, die Verbindung zum SmarthomeNG wird offensichtlich nicht aufgebaut: die Visu hat keine Funktion und der Auto Re-Connect springt an.

Klappt das Konstrukt bei jemanden von euch auch auf iOS?

[thoms3n]

Funktioniert tatsächlich! Sehr cool!

Probleme habe ich "nur" bei iOS. Egal welcher Browser, die Verbindung zum SmarthomeNG wird offensichtlich nicht aufgebaut: die Visu hat keine Funktion und der Auto Re-Connect springt an.

Klappt das Konstrukt bei jemanden von euch auch auf iOS?

Ich habe ebenfalls das iOS Problem (aber nur ein iOS Gerät daher keine Prio...) Welche nginx Version verwendest du? Das ist wohl in den neuen Versionen behoben.
Ich nutze aktuell eine uralte aus Debian stable und werde heute Abend mal updaten.
http://forum.directadmin.com/showthread.php?t=53570

[malte]

Läuft bei mir auf einer Synology - mit dem Original-Paket von denen: nginx version: nginx/1.11.10. Die Version ist wohl vom 14. Februar 2017. Lt. deinem Link ist die nicht mehr betroffen.

Aktuell ist 1.12.0. Ob ich die auf die Synology braten will ... mal gucken.

[malte]

thoms3n: wie sieht es bei dir nach dem Upgrade aus? Ich habe noch was gegoogelt und gebastelt - aber bisher ohne Erfolg.

[thoms3n]

malte, das ganze scheint ein SSL Problem zu sein. Irgendwie scheint der nginx manchmal (und bei einem ios client immer) das SSL Offloading nicht richtig zu machen. Im Debug Log sind auch SSL fehler zu sehen.
Der ReverseProxy mit HTTP (Port80) klappt bestens.

[psilo]

Hallo,

habe das Beispiel nun bei mir auch integriert, wobei bei mir die SV auf eine Maschine hinter den ReverseProxy läuft. Geht einwandfrei - mind. auf Android.

smai irgendwie zeigt die SV2.9 in der Admin nicht an, dass ich Port 443 als Websocket Port konfiguriert habe, obwohl im INI File der Richtige steht, steht in der GUI 2424?!

[psilo]

Mal eine dumme Frage: Port 443 ist gemäß der hier diskutierten Lösung dann doch für jegliche Websocketverbindung offen im Netz via Port 443 erreichbar, richtig?
Das ist natürlich etwas unschön...

PS: ok sehe gerade, dass Clientzertifikate genutzt werden.. Dann muss ich das wohl auch noch einrichten.

PPS: Nach Installation eines Clientzertifikats geht nun auch alles. habe es sogar hinbekommen, dass bestimmte Pfade nur via Basic Auth, andere via Clientzertifikat gesichert sind.

[McTao]

Nach Installation eines Clientzertifikats geht nun auch alles. habe es sogar hinbekommen, dass bestimmte Pfade nur via Basic Auth, andere via Clientzertifikat gesichert sind.

Kannst du eine anonymisierte Einstellungsdaten (proxy conf) posten. Ich habe das zwar mal vor Jahren unter Apache gemacht, möchte aber nicht wieder von vorne anfangen. Eine Conf kann ich lesen und mit meinem alten Wissen dann anpassen. Besonders der Teil mit der unterschiedl. Auth klingt interessant.

Würde es dann in der Apple Welt nutzen.

Gruss Andreas

[malte]

McTao: die "Apple Welt" scheint aktuell leider abgehangen zu sein. Die entsprechenden Configs findest du eigentlich vollständig in den vorherigen Posts:
#17: Überblick
#12: Config

Wenn du es auf MacOS und/oder iOS ans Laufen gebracht hast, lass es mich wissen ;-)

[psilo]

Vielleicht hier die Variante, die ich verwende, um die Clientzertifikate nur auf / (für die Websocket-Connection bzw auf /smartVISU einzusetzen, und auf allem anderen nicht. Im Beispiel das Network Plugin von SHNG (für EgiGeoZone) ohne Clientzertifikate nur mit Basic Auth.

Auf iOS habe ichs aber noch nicht getestet, da wo ich die Lösung her hatte stand, dass Safari hier wohl manchmal Probleme macht:

ssl_verify_client optional;
ssl_session_timeout 5m;
[...]
location / {
        if ($ssl_client_verify != SUCCESS) {
                        return 403;
                        break;
                }

        if ($http_upgrade = websocket) {
            proxy_pass http://192.168.178.100:2424;
        }
        if ($http_upgrade != websocket) {
             return 403;
        }
    }

location /smartVISU {
        if ($ssl_client_verify != SUCCESS) {
            return 403;
            break;
        }

        if ($allowed_country = no)  {
                return 403;
        }
        proxy_pass https://192.168.178.100/smartVISU;
        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;
}

location /shng {
        auth_basic "Restricted Area: SmartHomeNG";
        auth_basic_user_file /etc/nginx/.shng;

        if ($allowed_country = no) {
            return 403;
        }
        proxy_pass http://192.168.178.100:8888/;
        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;
    }

Und das hier war sehr sinnvoll für die Client-Zertifikate Erstellung: https://arcweb.co/securing-websites-...ication-linux/

[Max2612]

Hallo Miteinander!

Ich stehe auch gerade vor dem Problem, dass die Visu hinter meinem Reverse-Proxy zwar erreichbar ist, aber im Offline-Modus.
Meine nginx Konfiguration sieht im Moment so aus: (nginx war nötig, um das Alexa Plugin zu nutzen)

upstream php {    
  server localhost:9090;
}    

server {    
  listen 80 default_server;    
  server_name xyz.spdns.eu;    
  satisfy any;    
  allow 192.168.1.0/24;    
  deny all;    
  auth_basic "SmartVisu Anmeldung";    
  auth_basic_user_file /etc/nginx/htpasswd.smartvisu;    
  root /var/www/html;    
  index index.php index.html index.htm;    

  location / {      
     autoindex on;    
  }    

  location ~ \.php$ {      
    include /etc/nginx/fastcgi_params;          
    fastcgi_pass 127.0.0.1:9090;          
    fastcgi_read_timeout 300;        
    fastcgi_index index.php;      
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;  
  }    

 location /.well-known {              
    allow all;    
  }

}  
 # Alexa  

server {    
  listen 443 ssl default_server;    
  server_name xyz.spdns.eu;    
  access_log /var/log/nginx/alexa.log combined;    
  auth_basic "Alexa";    
  auth_basic_user_file /etc/nginx/htpasswd.alexa;    
  include /etc/nginx/include.d/common;      

  location / {        
    proxy_pass http://192.168.1.13:9000/;    
    proxy_set_header Host $host;        
    proxy_set_header X-Real-IP $remote_addr;        
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;    
  }  
}

Ich habe aber leider keine Ahnung, wie ich diese nun ändern muss, dass auch der Websocket funktioniert.
Kann mir hier jemand dabei helfen?

Gruß, Max

[psilo]

wo ist die weiterleitungsregel für deine websocket verbindung?

im anderen thread habe ich mein beispiel gepostet.

das sind übrigens meine websocket anteile:

    location / {    
[COLOR=#FF0000]     if ($ssl_client_verify != SUCCESS) {
            return 403;
             break;
        }[/COLOR]

        if ($http_upgrade = websocket) {
            proxy_pass http://192.168.178.100:2424;
        }
        if ($http_upgrade != websocket) {
             return 403;
        }
    }

der rote Teil ist für meine Clientzertifikate.

die websockets gehen nicht auf einen kontextpfad, daher musst du sie auf "/" durchrouten. ob man einen pfad in der SV konfig mit angeben kann, habe ich nicht probiert.

in der config.ini muss deine dyndns domain rein und der ssl port:

driver_address = "xxx.dyndns.de"
driver_port = "443"

dann gab es da noch einen bug mit der konfiguration und dem smarthome_io treiber. ich weiss nicht, ob smai das inzwischen behoben hat? ich musste den 443er auch noch direkt in den driver reinschreiben

PS: NGINX auf einer eigenen Hardware vor SmartVisu und SHNG ist eine super Sache. Du solltest aber wirklich verstehen, was Deine Regeln machen. Fang ab besten bei Null an und kopiere nicht blind Beispiele rein. Sonst hast du am Ende eine vollkommen unsichere Konfiguration.. Man kann auch viel falsch machen.

Ich kann auch schwer empfehlen, sich in das Thema Security in diesem Kontext etwas einzulesen.

Und wenn das alles zu hoch ist: Alexa via NGINX und Basic Auth. SmartVISU nur im VPN... dann ist alles easy und Du kannst lokale IPs nehmen und NGINX wird übersprungen, wenn Du es richtig machst..