Falscher redirect bei nginx

ari · 3 Mai 2019

Ich stehe vor folgendem Problem: Ich habe einen Webserver, der Anfragen aus dem Netz durch einen VPN-Tunnel an eine PHP-Applikation auf einem lokalen Webserver weiterleitet .. oder zumindest weiterleiten soll. Das Setup sieht so aus:

Code:

< Internet > ----- | nginx auf meinserver.de | ----- VPN-Tunnel (Wireguard) ----- | nginx / PHP-Applikation auf meinserver.local

Meine Konfigurationsdateien sind wie folgt, externer nginx:

Code:

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name meinserver.de;

    #access_log off;
    #error_log off;

    ssl_certificate /etc/nginx/ssl/meinserver.de.crt;
    ssl_certificate_key /etc/nginx/ssl/meinserver.de.key;
		
	location /jukebox/ {
		rewrite ^/jukebox(.*) $1 break;
		proxy_pass https://jukebox.meinserver.local/;
		proxy_set_header X-Real-IP $remote_addr;
		proxy_set_header Host $host;
		proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
	}

}

Interner nginx:

Code:

upstream php-fpm {                                                              
    server unix:/var/run/php/php7.0-fpm.sock;                                          
}

server {
    listen      443 ssl;
    server_name meinserver.local;
    root        /var/www/sonerezh/app/webroot;

    ssl_certificate /etc/nginx/tls/meinserver.local.crt;
    ssl_certificate_key /etc/nginx/tls/meinserver.local.key;

    index index.php;

    location / {
        try_files $uri $uri/ /index.php?$args;
        expires 14d;
        add_header Cache-Control 'public';
    }

    # The section below handle the thumbnails cache, on the client (browser)
    # side (optional but recommended)
    location ~* /([^/]+_[0-9]+x[0-9]+(@[0-9]+x)?\.[a-z]+)$ {
        try_files /img/resized/$1 /index.php?$args;
        add_header Cache-Control 'public';
        expires 14d;
        access_log off;
    }

    location ~ \.php$ {
        try_files $uri =404;
        fastcgi_index index.php;
        fastcgi_pass php-fpm;
        include fastcgi.conf;
    }
}

Der VPN-Tunnel steht, die beiden Server können miteinander kommunizieren und die verwendeten, selbsterstellten Zertifikate für den lokalen Webserver sind beidseitig getrusted. Nachdem die Webapplikation unter "/" erreichbar ist, und der Request via /jukebox kommt, entferne ich den Teil des Requests. Das Ergebnis verwirrt mich aber total, .. der Request erreicht den internen Webserver zwar, dieser leitet dann aber weiter auf https://meinserver.de/login anstatt die Anfrage korrekt an die lokale Applikation weiterzuleiten. Das sieht in den (lokalen) Logs dann etwa so aus:

Code:

10.200.200.1 - - [03/May/2019:21:06:20 +0200] "GET / HTTP/1.0" 302 0 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:66.0) Gecko/20100101 Firefox/66.0"

Ich bin mir absolut sicher, dass mein Fehler trivialer Natur ist & ich einfach nur unter Betriebsblindheit leide. Kann jemand so nett sein, und mich in die richtige Richtung stossen? Danke.

gadean · 4 Mai 2019

Ich werde aus dem Post nicht ganz schlau und deine Configs sehen merkwürdig aus. Dein Reverse-Proxy hört auf "meinserver.de", dein Upstream auf "meinserver.local", du leitest vom RP zum Upstream mit "https://jukebox.meinserver.local/" und setz als Hostnamen für den Request "$host" (was glaube ich "meinserver.de" wäre)?

Naja das 302 im Log riecht nach "Location"-Header, versuch es mal mit proxy_redirect.

Code:

proxy_redirect http://localhost:8000/two/ http://frontend/one/;

ari · 4 Mai 2019

Mal ganz untechnisch erklärt: Ich habe einen Webserver auf einer gemieteten Kisten laufen, der mittels eines VPN-Tunnels in mein lokales Netz kann, wo, hinter einem lokalen Webserver, eine PHP-Applikation (Sonerezh) läuft, die meine lokale Musiksammlung im Browser verfügbar machen soll. Ziel ist es, dass ich von überall auf meine Musik zugreifen kann. Und ich krieg's nicht hin, dass der externe Webserver, der hier Reverse Proxy spielt, die Requests sauber durchleitet.

Die Config auf meinem externen Webserver sieht jetzt so aus:

Code:

	location /jukebox {
		proxy_pass https://jukebox.meinserver.local/;
		proxy_redirect https://jukebox.meinserver.local /jukebox;
		proxy_set_header X-Real-IP $remote_addr;
		proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
	}

Jetzt komme ich zwar zu der Loginmaske (ohne CSS / JS, weil die Requests nicht weitergegeben werden), aber sobald ich mich einloggen will erfolgt die Weiterleitung direkt auf meinserver.de/login, also irgendwas stimmt mit den Pfaden nicht ganz.

Edit: Ich hab das Problem jetzt einfach mit Ressourcen erschlagen und der Applikation eine Subdomain verpasst .. da ist schon viel zu viel Zeit reingeflossen. Danke trotzdem für die Hilfe!

gadean · 4 Mai 2019

Ok, also nur mal als Beispiel, das hier ist eine der Configs die ich benutzte:
Der Reverse-Proxy hört auf den Namen "foobar.de", der Upstream hört ebenfalls auf den Namen "foobar.de" (Edit: siehe unten).
Der Upstream liefert im "Location" Header unter anderem "http://foobar.de/blabla" zurück, was mit "proxy_redirect" umgeschrieben wird.
Der Http-Header "Host" (config: "server_name") ist gerade bei TLS (SNI) sehr wichtig.
Den Http-Header "Accept-Encoding" setzte ich beim weiterleiten zum Upstream auf "" um gzip zu deaktivieren, da ich im Body noch Werte ersetzte (das sollte aber für dich erst mal irrelevant sein und ist nicht in der Config enthalten).

Wie die Config beim Upstream aussehen muss, kann ich dir leider nicht sagen, habe nginx nie mit php betrieben :/

Code:

server {
  listen 80;
  listen [::]:80;

  server_name foobar.de;

  return 301 https://$host$request_uri;
}

server {
  listen 443 ssl http2;
  listen [::]:443 ssl http2;

  server_name foobar.de;
  # security headers
  add_header X-Frame-Options "SAMEORIGIN" always;
  add_header X-XSS-Protection "1; mode=block" always;
  add_header X-Content-Type-Options "nosniff" always;
  add_header Referrer-Policy "no-referrer-when-downgrade" always;
  add_header Content-Security-Policy "default-src * data: 'unsafe-eval' 'unsafe-inline'" always;
  add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

  # . files
  location ~ /\.(?!well-known) {
    deny all;
  }

  # gzip
  gzip on;
  gzip_vary on;
  gzip_proxied any;
  gzip_comp_level 6;
  gzip_types text/plain text/css text/xml application/json application/javascript application/xml+rss application/atom+xml image/svg+xml;

  # SSL
  ssl_certificate certs/foobar.de.crt;
  ssl_certificate_key certs/foobar.de.key;

  # reverse proxy
  location / {
    proxy_pass http://192.168.1.41;
    proxy_redirect http://foobar.de https://foobar.de;
    
    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;
    proxy_set_header X-Forwarded-Host $host;
    proxy_set_header X-Forwarded-Port $server_port;
    proxy_set_header Accept-Encoding "";
    proxy_read_timeout 150;
  }
}

Anmerkung/Edit:
Bitte nicht mit den Hostnamen der Maschinen verwechseln, die lauten komplett anders und sind in dem Kontext irrelevant.

Falscher redirect bei nginx

ari

Well-Known Member

gadean

Depp vom Dienst!

ari

Well-Known Member

gadean

Depp vom Dienst!

Wir schützen deine Privatsphäre