Reverse Proxy

[Max2612]

OK, danke, alles klar.
Dann warte ich gleich auf morgen und richte alles auf 2 getrennten Systemen ein.

Raspi 1: Nginx
Raspi 2: sh und sv mit Apache

Nginx leitet auf http von Raspi2, richtig??

[psilo]

je nachdem ob die visu unterm apache laeuft. ich nehme an das tut sie. wenn du den stoppst kann sie ja garnicht gehen..

starte den apache doch mit port 80 (ist er wahrsch. sowieso) und lass nginx auf 443. und aender die weiterleitung auf http. dann sollte es jetzt schon gehen

[Max2612]

Apache ist gestoppt.
Das heißt, auf dem Raspi, wo die Visu drauf ist, kann der Apache bleiben?

[psilo]

oder du richtest nginx mit php ein.. und hostest die sv dort

ich finde die 'physikalische' trennung aber generell sinnvoll...

[psilo]

naja deine sv laeuft auf nem apache Webserver, der nginx ist ein eigener. die kommen vermutlich in konflikt. geht die sv wenn du nginx stoppst?

[Max2612]

Weder im LAN, noch von extern ist die Visu erreichbar. Egal ob http oder https.

Nginx läuft auf dem gleichen Raspi wie smartvisu. Dann ist das vielleicht das Problem?
Ich habe schon einen 2. Raspi bestellt. Der sollte morgen kommen.

[psilo]

achja und der nginx laeuft sicher auf einer anderen kiste? sonst geht die weiterleitung auf https und 'sich selber' womoeglich wieder gg den nginx.. geht die smartvisu im lan?

[psilo]

bei mir ist sie auf dem nas auch via https angebunden. ich vermute bei dir nicht

[psilo]

ist die smartvisu auf der ziel ip via http oder https erreichbar?

[Max2612]

Der nginx startet ohne Fehler mit dieser config:

server {
    server_tokens off;

    listen 443 ssl default_server;
    server_name xxx.eu;

    ##
    # SSL
    ##

    ssl on;
    ssl_certificate /etc/letsencrypt/live/xxx.eu/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/xxx.eu/privkey.pem;
    ssl_session_cache builtin:1000 shared:SSL:10m;
    ssl_ciphers    HIGH:!aNULL:!eNULL:!LOW:!3DES:!MD5:!RC4;

    add_header Strict-Transport-Security "max-age 31536000; includeSubDomains";

    ##
    # global
    ##

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


  location /smartVISU {

        auth_basic "Restricted Area: smartVISU";
        auth_basic_user_file /etc/nginx/.htpasswd;


        proxy_pass https://192.168.1.13/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;
    }
}

Beim Aufruf kommt die Anmeldung. Dann bekomme ich einen "400 Bad Request"

ErrorLog bleibt leer.
AccessLog

192.168.1.13 - xxx [27/Sep/2017:19:44:50 +0200] "GET /smartVISU HTTP/1.0" 400 242 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36"
192.168.1.31 - xxx [27/Sep/2017:19:44:50 +0200] "GET /smartVISU HTTP/1.1" 400 242 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36"

[psilo]

z.b. dieser art:
aaa.bbb.xxx.yyy - - [25/Sep/2017:08:41:43 +0000] "GET /smartVISU/lib/weather/pics/sun_2.png HTTP/1.1" 200 55685 "https://ccc.dyndns.de smartVISU/index.php" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:55.0) Gecko/20100101 Firefox/55.0"

[psilo]

Max2612 landen im nginx log fehler? erste anlaufstelle bei sowas
reloaded nginx erfolgreich mit der config?

da sollten die liegen

pi@reverseproxy:~ $ ls /var/log/nginx/
access.log             access.log.2.gz        error.log.16.gz
access.log.1           access.log.30.gz       error.log.17.gz
access.log.10.gz       access.log.31.gz       error.log.18.gz
access.log.11.gz       access.log.3.gz        error.log.19.gz
access.log.12.gz       access.log.4.gz        error.log.20.gz
access.log.13.gz       access.log.5.gz        error.log.21.gz
access.log.14.gz       access.log.6.gz        error.log.22.gz
access.log.15.gz       access.log.7.gz        error.log.23.gz
access.log.16.gz       access.log.8.gz        error.log.24.gz
access.log.17.gz       access.log.9.gz        error.log.25.gz
access.log.18.gz       allowed_country.log    error.log.26.gz
access.log.19.gz       allowed_country.log.1  error.log.27.gz
access.log.20.gz       country.log            error.log.28.gz
access.log.21.gz       country.log.1          error.log.29.gz
access.log.22.gz       error.log              error.log.2.gz
access.log.23.gz       error.log.1            error.log.3.gz
access.log.24.gz       error.log.10.gz        error.log.4.gz
access.log.25.gz       error.log.11.gz        error.log.5.gz
access.log.26.gz       error.log.12.gz        error.log.6.gz
access.log.27.gz       error.log.13.gz        error.log.7.gz
access.log.28.gz       error.log.14.gz        error.log.8.gz
access.log.29.gz       error.log.15.gz        error.log.9.gz

loggt das access log zugriffe?

[Max2612]

die CRTs usw. im 2ten block sind für die certificate authority: so kann der server clientzertifikate authorisieren (hast du mal https://arcweb.co/securing-websites-...ication-linux/ angeschaut - stand im kommentar verlinkt?)

Ja, hab ich mir angeschaut. Mir war nur nicht ganz klar, für was die CRT's benötigt werden.

ich hätte in deinem beispiel gesagt, dass wenn letsencrypt (also die serverzertifikate) passt, die smartvisu (aber noch ohne websocketverbindung!) per https gehen sollte..

Und genau das verstehe ich nicht. Ich komme nicht auf die Visu. Die IP der Visu habe ich angepasst. (proxy_pass https://192.168.1.13/smartVISU;)

[psilo]

achja noch ne frage: stimmt das bei dir?

proxy_pass https://192.168.178.100/smartVISU;

also läuft die SV bei dir auch auf dieser IP?

[psilo]

Max2612 ohje lange ists her die 2 ausdrücke im ersten block sind die ssl serverzertifikate für meine domain (daher letsencrypt)

die CRTs usw. im 2ten block sind für die certificate authority: so kann der server clientzertifikate authorisieren (hast du mal https://arcweb.co/securing-websites-...ication-linux/ angeschaut - stand im kommentar verlinkt?)

ich hätte in deinem beispiel gesagt, dass wenn letsencrypt (also die serverzertifikate) passt, die smartvisu (aber noch ohne websocketverbindung!) per https gehen sollte..

für die websockets ist das wie gesagt nochmal eine andere sache. meiner meinung nach geht eine basic auth nicht mit websockets. deshalb kamen dann die clientzertifikate ins spiel, da ich die websocket connection nicht offen im internet haben wollte...