11
Reverse Proxy nginx leitet auf IP weiter
Moin!
Ich spiele derzeit mit einem Debian ReverseProxy (nginx) und einer Debian NextCloud (ebenfalls nginx) herum. Beide befinden sich als VM auf einem Host im selben Netzwerk.
Mitlerweile habe ich mehrfach beide Maschinen neuinstalliert, jedoch imemr mit dem selben Effekt am Ende - sobald der nginx auf der NextCloud läuft (nach der Konfiguration, bei der Installation alles okay) klappt mein Proxy nicht mehr. Er leitet, wenn ich im Browser die URL angebe nicht mehr zur VM weiter, sondern ändert die URL auf die IP Adresse der VM.
Konfiguration Reverse-Proxy:
Folgende Anleitungen habe ich verwendet. Der Proxy macht gleichzeitig auf die SSL-Zertifikate, sodass ich den Part in der Anleitung der NC weggelassen habe und entsprechende Zeilen im Code auskommentiert habe.
Anleitung NextCloud-Installation
Anleitung Reverse-Proxy
Ich denke, der Fehler liegt auf der NC-VM, da ein anderer Webserver im Netz auf dem sich nginx "pur" befindet mit dem Proxy ohne Probleme klar kommt. Leider sehe ich den Wald vor lauter Bäume nicht.
Viele Grüße, und einen ruhigen Start in die Woche!
Ich spiele derzeit mit einem Debian ReverseProxy (nginx) und einer Debian NextCloud (ebenfalls nginx) herum. Beide befinden sich als VM auf einem Host im selben Netzwerk.
Mitlerweile habe ich mehrfach beide Maschinen neuinstalliert, jedoch imemr mit dem selben Effekt am Ende - sobald der nginx auf der NextCloud läuft (nach der Konfiguration, bei der Installation alles okay) klappt mein Proxy nicht mehr. Er leitet, wenn ich im Browser die URL angebe nicht mehr zur VM weiter, sondern ändert die URL auf die IP Adresse der VM.
Konfiguration Reverse-Proxy:
server {
server_name cloud.xyz.de;
location / {
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 https;
proxy_set_header X-Forwarded-Port 443;
proxy_pass http://172.16.1.248:80;
}
client_max_body_size 0;
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/cloud.xyz.de/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/cloud.xyz.de/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}
server {
if ($host = cloud.xyz.de) {
return 301 https://$host$request_uri;
} # managed by Certbot
server_name cloud.xyz.de;
listen 80;
return 404; # managed by Certbot
}Folgende Anleitungen habe ich verwendet. Der Proxy macht gleichzeitig auf die SSL-Zertifikate, sodass ich den Part in der Anleitung der NC weggelassen habe und entsprechende Zeilen im Code auskommentiert habe.
Anleitung NextCloud-Installation
Anleitung Reverse-Proxy
Ich denke, der Fehler liegt auf der NC-VM, da ein anderer Webserver im Netz auf dem sich nginx "pur" befindet mit dem Proxy ohne Probleme klar kommt. Leider sehe ich den Wald vor lauter Bäume nicht.
Viele Grüße, und einen ruhigen Start in die Woche!
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 3001490754
Url: https://administrator.de/forum/reverse-proxy-nginx-leitet-auf-ip-weiter-3001490754.html
Ausgedruckt am: 30.12.2024 um 17:12 Uhr
11 Kommentare
Neuester Kommentar
Hallo,
Du must mit proxy_redirect auf dem Reverse-Proxy die Location-Header aus dem Backend maskieren.
Grüße
Richard
Du must mit proxy_redirect auf dem Reverse-Proxy die Location-Header aus dem Backend maskieren.
Grüße
Richard
Hi,
okay, verstehe leider nicht was genau du meinst. Ich lese mich derzeit noch in das ganze Thema ein. Was genau muss ich maskieren, bzw. wofür wird das Maskieren genutzt?
Ist das Backend die NC VM?
okay, verstehe leider nicht was genau du meinst. Ich lese mich derzeit noch in das ganze Thema ein. Was genau muss ich maskieren, bzw. wofür wird das Maskieren genutzt?
Ist das Backend die NC VM?
Moin,
was hast du denn in der Nginx Konfiguration für die NextCloud bei der Variable server_name angegeben?
Gruß,
Dani
was hast du denn in der Nginx Konfiguration für die NextCloud bei der Variable server_name angegeben?
Gruß,
Dani
Moin,
ich geh mal davon aus, dass du die /etc/nginx/conf.d/http.conf Datei meinst?
Dort habe ich cloud.xyz.de, genauso wie in der /etc/nginx/conf.d/nextcloud.conf angegeben.
Mitlerweile erhalten ich auch eine neue Fehlermeldung, too many http redirects.
ich geh mal davon aus, dass du die /etc/nginx/conf.d/http.conf Datei meinst?
Dort habe ich cloud.xyz.de, genauso wie in der /etc/nginx/conf.d/nextcloud.conf angegeben.
Mitlerweile erhalten ich auch eine neue Fehlermeldung, too many http redirects.
Zitat von @c0d3.r3d:
Hi,
okay, verstehe leider nicht was genau du meinst. Ich lese mich derzeit noch in das ganze Thema ein. Was genau muss ich maskieren, bzw. wofür wird das Maskieren genutzt?
Ist das Backend die NC VM?
Hi,
okay, verstehe leider nicht was genau du meinst. Ich lese mich derzeit noch in das ganze Thema ein. Was genau muss ich maskieren, bzw. wofür wird das Maskieren genutzt?
Ist das Backend die NC VM?
Ja, ich hätte besser Upstream schreiben sollen. Wie viele Anwendungen leitet NC u.a. beim Aufruf der Login-Seite mit 302 um. 3xx-Antworten enthalten die Ziel-URL in einem Location-Header. Bei einer absoluten URL wird deren Host-Bestandteil in der Regel aus dem Host-Header des Requests übernommen.
Für den Proxy ist der Host-Header des Client-Requests der beabsichtigte Hostname. Für NC hingegen ist es momentan die IP, unter der es vom Reverse-Proxy angesprochen wird. Der Proxy muss nun diesen Location-Header auf einen für seinen Hostnamen passenden umschreiben und darf ihn nicht 1:1 durchreichen.
Zur proxy_redirect-Direktive siehe die NGINX-Doku.
Zitat von @c.r.s.:
Wie viele Anwendungen leitet NC u.a. beim Aufruf der Login-Seite mit 302 um. 3xx-Antworten enthalten die Ziel-URL in einem Location-Header.
Wie viele Anwendungen leitet NC u.a. beim Aufruf der Login-Seite mit 302 um. 3xx-Antworten enthalten die Ziel-URL in einem Location-Header.
Okay.
Bei einer absoluten URL wird deren Host-Bestandteil in der Regel aus dem Host-Header des Requests übernommen.
Host-Header des Request = Clientname der Anfragt? z.B. das Smartphone?Für den Proxy ist der Host-Header des Client-Requests der beabsichtigte Hostname. Für NC hingegen ist es momentan die IP, unter der es vom Reverse-Proxy angesprochen wird.
Anfragendes Gerät = Host-Header im Proxy; bei Nextcloud ist der Header aber egal, da dort die IP reingeschrieben wird vom Reverse-Proxy?
Der Proxy muss nun diesen Location-Header auf einen für seinen Hostnamen passenden umschreiben und darf ihn nicht 1:1 durchreichen.
Ich verstehe was du meinst, allerdings fehlt mir jeglicher Schimmer, wie ich das umsetzen soll, da mir das Fachvokabular dann doch etwas zu hoch ist.Zur proxy_redirect-Direktive siehe die NGINX-Doku.
Schau ich mir an.Sei mir nicht böse, aber ich habe immernoch nicht wirklich verstanden, was du mir vermitteln möchtest. Ich habe das ganze jetzt so verstanden, dass die Anfrage an den Proxy von ClientA kommt, der Proxy die weiterleitet an die NextCloud, den Header von ClientA aber nicht übernimmt und sich dort selbst reinschreibt und dann volles Chaos entsteht.
Eine Schritt für Schritt Anleitung, wie ich mein Problem lösen könnte wäre ganz nett, mit kurzen und Verständlichen Erläuterungen.
Moin,
nehem proxy_redirect off; in deine Konfiguration für den Nginx als Reverse Proxy auf.
Wie immer ungetestet!
Gruß,
Dani
nehem proxy_redirect off; in deine Konfiguration für den Nginx als Reverse Proxy auf.
server {
server_name cloud.xyz.de;
location / {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_pass http://172.16.1.248:80;
proxy_redirect off;
}Eine Schritt für Schritt Anleitung, wie ich mein Problem lösen könnte wäre ganz nett, mit kurzen und Verständlichen Erläuterungen.
Damit kann und will ich nicht dienen. Wir sind in einem Forum und nicht ein IT-Dienstleister. Ein bisschen Eigeninitiative hat noch nie geschadet. Wenn du nicht weist was proxy_redirect tut, lese es im Handbuch nach.Gruß,
Dani
Zitat von @c0d3.r3d:
Eine Schritt für Schritt Anleitung, wie ich mein Problem lösen könnte wäre ganz nett, mit kurzen und Verständlichen Erläuterungen.
Eine Schritt für Schritt Anleitung, wie ich mein Problem lösen könnte wäre ganz nett, mit kurzen und Verständlichen Erläuterungen.
Öffne im Browser die Webentwickler-Tools (Netzwerkanalyse), schau die Request- und Response-Header an, dann verstehst du das und kannst es selbst debuggen. Der Request-Header namens "Host" ist der Hostname, unter dem du die Seite aufrufst (cloud.xyz.de).
Beim ersten Request auf die Login-Seite kommt ein 302 zurück mit einem Response-Header namens "Location". In der URL dort wird die NC-IP stehen, weil der Proxy NC unter dieser IP aufruft, und NC vom ursprünglichen Host-Header nichts weiß.
Damit kann und will ich nicht dienen. Wir sind in einem Forum und nicht ein IT-Dienstleister. Ein bisschen Eigeninitiative hat noch nie geschadet. Wenn du nicht weist was proxy_redirect tut, lese es im Handbuch nach.
Hi Dani,
da stimme ich dir voll und ganz zu. Mit Schritt für Schritt Anleitung meinte ich nicht eine fertige Musterlösung, sondern einen "Tritt" in die richtige Richtung, mit der ich selber nachvollziehen kann, was genau passiert und wo es hapert.
Zitat von @c.r.s.:
Öffne im Browser die Webentwickler-Tools (Netzwerkanalyse), schau die Request- und Response-Header an, dann verstehst du das und kannst es selbst debuggen. Der Request-Header namens "Host" ist der Hostname, unter dem du die Seite aufrufst (cloud.xyz.de).
Zitat von @c0d3.r3d:
Eine Schritt für Schritt Anleitung, wie ich mein Problem lösen könnte wäre ganz nett, mit kurzen und Verständlichen Erläuterungen.
Eine Schritt für Schritt Anleitung, wie ich mein Problem lösen könnte wäre ganz nett, mit kurzen und Verständlichen Erläuterungen.
Öffne im Browser die Webentwickler-Tools (Netzwerkanalyse), schau die Request- und Response-Header an, dann verstehst du das und kannst es selbst debuggen. Der Request-Header namens "Host" ist der Hostname, unter dem du die Seite aufrufst (cloud.xyz.de).
Habe ich getan. Dort steht tatsächlich im Anfrage-Header unter Host der Name der Cloud.
Beim ersten Request auf die Login-Seite kommt ein 302 zurück mit einem Response-Header namens "Location". In der URL dort wird die NC-IP stehen, weil der Proxy NC unter dieser IP aufruft, und NC vom ursprünglichen Host-Header nichts weiß.
Entweder liegt hier bereits das Problem, oder ich mache etwas falsch, denn ich bekomme nur 301 Moved Permanently zurück. (so ca. 20 mal)
Browsercache habe ich vorher natürlich gelöscht und den Browser neugestartet.
Zitat von @c0d3.r3d:
Entweder liegt hier bereits das Problem, oder ich mache etwas falsch, denn ich bekomme nur 301 Moved Permanently zurück. (so ca. 20 mal)
Entweder liegt hier bereits das Problem, oder ich mache etwas falsch, denn ich bekomme nur 301 Moved Permanently zurück. (so ca. 20 mal)
Weiß nicht, ob es das ist, aber der doppelte Server-Name hier hat mich schon etwas gestört:
server {
if ($host = cloud.xyz.de) {
return 301 https://$host$request_uri;
} # managed by Certbot
server_name cloud.xyz.de;
listen 80;
return 404; # managed by Certbot
} Den Server würde ich mal rausnehmen und https vorerst manuell aufrufen.
Ich nehme für die HTTP-Umleitung immer eine globale Konfiguration, in der nginx.conf und ohne Host-Matching, denn man will TLS ja doch für alle Sites:
# Redirect all HTTP traffic to HTTPS
server {
listen 80 default_server;
listen [::]:80 default_server;
return 301 https://$host$request_uri;
}
Interessant, warum auch immer konnte ich das Problem mit
in der /var/www/nextcloud/config/config.php Datei lösen.
...
'overwrite.cli.url' => 'https://cloud.xyz.de',
'overwritehost' => 'cloud.xyz.de',
...
