reverse proxy Bad Gateway

Debian macht sich hervorragend als Web- und Mailserver. Schau auch in den " Tipps und Tricks"-Bereich.
Antworten
Lockslay
Beiträge: 224
Registriert: 22.08.2002 17:51:19
Kontaktdaten:

reverse proxy Bad Gateway

Beitrag von Lockslay » 02.10.2024 14:27:26

Hallo zusammen,

ich möchte von einem nginx reverse proxy eine https Weiterleitung auf einen Virtuellen Host haben.

Der RP auf einem Proxmox und soll mittels "proxy_pass http://192.168.0.150:443;". auf den Webserver zugreifen bzw. weiterleiten.

Auf dem RP habe ich hier /etc/nginx/sites-available :

site.de-443.conf
site.de-80.conf

Code: Alles auswählen

server {
        listen 443 ssl;

        server_name site.de;

        root /var/www/sites/site.de;

        access_log   /var/log/nginx/site.de-443-access.log;
        error_log    /var/log/nginx/site.de-443-error.log;

        # With Nginx v1.15.2 the "ssl" directive is deprecated, this version is 1.14.2
#        ssl                  on;

        ssl_certificate /etc/letsencrypt/live/site.de/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/site.de/privkey.pem;

        include /etc/nginx/snippets/include.ssl-common;

        # when serving user-supplied content, include a X-Content-Type-Options: nosniff header along with the Content-Type: hea
der,
        # to disable content-type sniffing on some browsers.
        # https://www.owasp.org/index.php/List_of_useful_HTTP_headers
        # currently suppoorted in IE > 8 http://blogs.msdn.com/b/ie/archive/2008/09/02/ie8-security-part-vi-beta-2-update.aspx
        # http://msdn.microsoft.com/en-us/library/ie/gg622941(v=vs.85).aspx
        # 'soon' on Firefox https://bugzilla.mozilla.org/show_bug.cgi?id=471020
        add_header X-Content-Type-Options nosniff;

        # This header enables the Cross-site scripting (XSS) filter built into most recent web browsers.
        # It's usually enabled by default anyway, so the role of this header is to re-enable the filter for.
        # this particular website if it was disabled by the user.
        # https://www.owasp.org/index.php/List_of_useful_HTTP_headers
        add_header X-XSS-Protection "1; mode=block";

        # The following option enables or disables emitting nginx version on error pages and in the "Server" response header field:
        server_tokens off;

        location /nginx_status {
                stub_status on;
                access_log on;

                allow 127.0.0.1;
                deny all;
        }

        location / {

                access_log /var/log/nginx/site.de-443-access-upstream.log;
                error_log /var/log/nginx/site-443-error-upstream.log;

                # Extended buffer sizes
                proxy_buffers 8 16k;
                proxy_buffer_size 32k;

                proxy_pass https://192.168.0.150:443;
                # proxy_ssl_verify SHOULD be set of "on" later
                proxy_ssl_verify off;
                proxy_set_header X-Forwarded-For $remote_addr;
                proxy_set_header X-Forwarded-Proto $scheme;
                proxy_set_header Host $host;

                allow all;
                deny all;
        }

} # of server
Das gleiche, natürlich an 80 angepasst unter site.de-80.conf
Auf dem Webserver, habe ich

Code: Alles auswählen

server {
        listen 443 ssl;
        server_name blog.intern.site.de;

        root /var/www/sites/blog.intern.site.de;

        access_log   /var/log/nginx/blog.intern.site.de-443-access.log;
        error_log    /var/log/nginx/blog.intern.site.de-443-error.log;

        # The following option enables or disables emitting nginx version on error pages and in the "Server" response header fiel>
        server_tokens off;

        location / {

                allow all;
                deny all;
        }

} # of server

Das gleiche, natürlich an 80 angepasst unter site.de-80.conf
Die Zertifikate habe ich auf dem RP und möchte eigentlich ohne Zertifikate die Daten vom RP an den Webserver weitergeben.
Leider bekomme ich ein 502 Bad Gateway

curl -I https://192.168.0.150:443
curl: (7) Failed to connect to 192.168.0.150 port 443 after 0 ms: Couldn't connect to server
curl sagt mir schon den Fehler, nur wie bekomme ich den Webserver dazu auf 443 zu Antworten?

Benutzeravatar
heisenberg
Beiträge: 4123
Registriert: 04.06.2015 01:17:27
Lizenz eigener Beiträge: MIT Lizenz

Re: reverse proxy Bad Gateway

Beitrag von heisenberg » 02.10.2024 14:49:56

Lockslay hat geschrieben: ↑ zum Beitrag ↑
02.10.2024 14:27:26

Code: Alles auswählen

server {
        listen 443 ssl;
        server_name blog.intern.site.de;

        root /var/www/sites/blog.intern.site.de;

        access_log   /var/log/nginx/blog.intern.site.de-443-access.log;
        error_log    /var/log/nginx/blog.intern.site.de-443-error.log;

        # The following option enables or disables emitting nginx version on error pages and in the "Server" response header fiel>
        server_tokens off;

        location / {

                allow all;
                deny all;
        }

}
Fehler, die ich sehe:
  1. Du hast auf dem Backend-Webserver eine VHost-Konfiguration auf Port 443 mit aktiviertem SSL aber ohne Zertifikatsdefinitionen. Das kann so nicht gehen. Läuft der nginx auf dem Backendserver überhaupt (netstat -nltp bzw. ss -ntlp) oder startet der nginx-Dienst wegen Fehlkonfiguration erst gar nicht?
  2. Du hast Deinen Reverse-Proxy so konfiguriert, dass er den Hostnamen "site.de" an den Backend-Server weitergibt. Der Backend-Server ist aber mit dem Hostname "blog.intern.site.de" konfiguriert. Auf diese Weise wird der Virtualhost nicht greifen. Die Namen müssen identisch sein oder der Backend-Server braucht einen Wildcard-Namen als Hostnamen.

Lockslay
Beiträge: 224
Registriert: 22.08.2002 17:51:19
Kontaktdaten:

Re: reverse proxy Bad Gateway

Beitrag von Lockslay » 02.10.2024 15:25:22

Hallo,

netstat -nltp

Code: Alles auswählen

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      4200/nginx: master  
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      4200/nginx: master  
tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN      278/master          
tcp6       0      0 :::22                   :::*                    LISTEN      1/init              
tcp6       0      0 :::80                   :::*                    LISTEN      4200/nginx: master  
tcp6       0      0 ::1:25                  :::*                    LISTEN      278/master   
Das sieht gut aus.
Verstehe ich das richtig, dass ich in der RP und im Werbserver die gleichen Namen haben muss
?

Code: Alles auswählen

server {
        listen 80;
        server_name site.de;

        root /var/www/sites/site.de;
müssen auf beiden auf site.de stehen?

Auf dem Webserver habe ich jetz nur noch die site.de-80.confund auf dem RP habe ich in der /etc/nginx/sites-available/site-443.conf". proxy_pass http://192.168.0.150:80;". eingestellt.

Benutzeravatar
heisenberg
Beiträge: 4123
Registriert: 04.06.2015 01:17:27
Lizenz eigener Beiträge: MIT Lizenz

Re: reverse proxy Bad Gateway

Beitrag von heisenberg » 02.10.2024 15:36:04

Lockslay hat geschrieben: ↑ zum Beitrag ↑
02.10.2024 15:25:22
Verstehe ich das richtig, dass ich in der RP und im Werbserver die gleichen Namen haben muss?
Nein, das nicht. Aber wenn Du einen Reverse-Proxy konfigurierst, dann musst Du den Hostnamen weitergeben, den der Backendserver auch entsprechend verarbeitet.

Konkret bei Dir:

Reverse-Proxy

Code: Alles auswählen

server {
        listen 443 ssl;
        server_name site.de;

        location / {

                proxy_pass https://192.168.0.150:443;
                proxy_ssl_verify off;
                proxy_set_header Host $host;
        }
}
Du hast den VHost-Namen "site.de" definiert. So muss der Server im Browser eingegeben werden. Dann hast Du eine Direktive proxy_set_header $host; Das bedeutet, dass der aufgerufene Hostname direkt weiter gegeben wird.

Der Backend-Server ist aber konfiguriert mit:

Code: Alles auswählen

server {
        listen 443 ssl;
        server_name blog.intern.site.de;
}
D. h. die beiden Namen passen nicht zusammen. Mögliche Lösungen:
  1. Du konfigurierst auf dem Backend-Server einen Catch-All-Hostnamen ( server_name _; )
  2. Du reichst auf dem Reverse-Proxy den Hostnamen weiter, den der Backend-Server haben möchte (proxy_set_header Host blog.intern.site.de;)
Ansonsten würde ich auf der Reverse-Proxy-Seite erst mal mit einer minimalen Konfiguration beginnen. Wenn dass dann läuft, dann würde ich die Konfiguration Schritt für Schritt erweitern.

Ansonsten

Code: Alles auswählen

curl -I https://192.168.0.150:443
curl: (7) Failed to connect to 192.168.0.150 port 443 after 0 ms: Couldn't connect to server
Das sollte eigentlich schon vom RP aus funktionieren, auch wenn der VHost gemäß Deiner hier gezeigten Konfiguration auf dem Backend-Server natürlich nicht auf den Virtualhost 192.168.0.150 konfiguriert ist. (Der VHostname ist "blog.intern.site.de"). Aber die Fehlermeldung passt nicht dazu. Den Port sollte er schon öffnen könne, es sei denn der Webserver auf dem Backend läuft nicht, oder ist per Firewallregel geblockt.

Lockslay
Beiträge: 224
Registriert: 22.08.2002 17:51:19
Kontaktdaten:

Re: reverse proxy Bad Gateway

Beitrag von Lockslay » 02.10.2024 19:50:10

Hallo und danke für die wichtigen Hinweise.

Was aber grundsätzlich schief läuft ist doch das:

Code: Alles auswählen

curl -I https://192.168.0.150:80
curl: (35) OpenSSL/3.0.14: error:0A00010B:SSL routines::wrong version number

Code: Alles auswählen

curl -I https://192.168.0.150:443
curl: (7) Failed to connect to 192.168.0.150 port 443 after 0 ms: Couldn't connect to server
Die beiden Anfragen habe ich vom RP an den Webserver gestellt.
Wenn beide Port 80 und 443 nicht antworten, dann ist am Webserver etwas komsich eingestellt.
Oder bin ich hier auf dem Holzweg?

Benutzeravatar
heisenberg
Beiträge: 4123
Registriert: 04.06.2015 01:17:27
Lizenz eigener Beiträge: MIT Lizenz

Re: reverse proxy Bad Gateway

Beitrag von heisenberg » 02.10.2024 20:49:27

Lockslay hat geschrieben: ↑ zum Beitrag ↑
02.10.2024 19:50:10

Code: Alles auswählen

curl -I https://192.168.0.150:80
curl: (35) OpenSSL/3.0.14: error:0A00010B:SSL routines::wrong version number
Eine HTTPS-Abfrage an einen Non-SSL-Webserver ("Webserver" meint hier den spezifischen Dienst hinter einem spezifischen Port, hier also der nginx, der mit speziellen Einstellungen den Port 80 bedient.) kann nicht funktionieren. Aber ansonsten bedeutet die Ausgabe schon mal, dass da eine Antwort kommt. Nur halt nicht das, was Du mit Deinem Befehl anfragst. Richtig wäre (http und nicht https):

Code: Alles auswählen

curl -I http://192.168.0.150
---

Code: Alles auswählen

curl -I https://192.168.0.150:443
curl: (7) Failed to connect to 192.168.0.150 port 443 after 0 ms: Couldn't connect to server
Wie geschrieben: Vermutlich ein Firewall Problem.

Was ergibt denn auf dem RP ein nmap -p443 192.168.0.150 ( Debiannmap musst Du dort vermutlich erst installieren ) ?

---

Ansonsten kannst Du den Port in der URL auch weglassen, wenn es der Standardport ist. Und für http ist 80 der Standardport und für https ist 443 der Standardport.

---

Nachtrag

Wenn ich Deine Beiträge so durchlese, dann sind da ein paar Stellen, wo Du übliche Ports und Protokolle verwechselst. Da frage ich mich ob das nur Schreibfehler in den Beiträgen sind oder ob Du dass tatsächlich auch in den Konfigurationen oder in Befehlen durcheinander bringst.

Konkret:
  • HTTP also unverschlüsselt ist per Vereinbarung das, was hinter einem Port 80 läuft. Da läuft niemals ein SSL/TLS-Webserver.
  • HTTPS also verschlüsselt ist per Vereinbarung das, was hinter einem Port 443 läuft. Da läuft niemals unverschlüsselter Webserver.
  • Die Protokollbezeichnung http:// steht für unverschlüsseltes HTTP mit dem Standardport 80. Der Port muss in der URL nicht angegeben werden.
  • Die Protokollbezeichnung https:// steht für verschlüsseltes HTTPS mit dem Standardport 443. Der Port muss in der URL nicht angegeben werden.
  • Grundsätzlich kann man Webserver auch so konfigurieren, dass diese das anders tun. Aber das macht niemand, aus dem Grund weil es dann sehr viel Verwirrung stiftet.
  • Beides, sowohl HTTP als auch HTTPS kann grundsätzlich auf einem beliebigen Port lauschen. Das ist mitunter auch notwendig, weil manche Webserver erst mal selbst ihren eigenen Port öffnen und 80 bzw. 443 gibt es halt pro Host bzw. IP-Adresse nur einmal.
In Beispielen
  • http://192.168.1.2 bezeichnet eine unverschlüsselte Verbindung auf Port 80
  • http://192.168.1.2:80 bezeichnet das gleiche wie das Vorige
  • https://192.168.1.2 bezeichnet eine verschlüsselte Verbindung auf Port 443
  • https://192.168.1.2:443 bezeichnet das gleiche wie das Vorige
  • https://192.168.1.2:80 (=SSL-Verbindung auf Port 80) ist konfigurierbar, aber maximal verwirrend und deswegen mit an Sicherheit grenzender Wahrscheinlichkeit falsch bzw. extrem ungeschickt
  • http://192.168.1.2:443 (=unverschlüsselte Verbindung auf Port 443) ist konfigurierbar, aber maximal verwirrend und deswegen mit an Sicherheit grenzender Wahrscheinlichkeit falsch, bzw. extrem ungeschickt.
Wenn man Ports mit dem falschen Protokoll anspricht, bekommt man spezifische Fehlermeldungen. Die Fehlermeldungen sollte man mal gesehen haben, denn es kann ja mal sein, dass man aus Versehen etwas falsch konfiguriert hat:
  • HTTP-Request auf Port 443 bzw. HTTPS-Server

    Code: Alles auswählen

    wget --spider http://debianforum.de:443
    Spider-Modus eingeschaltet. Es wird geprüft, ob die Datei auf dem Server existiert.
    --2024-10-02 23:49:03--  http://debianforum.de:443/
    Auflösen des Hostnamens debianforum.de (debianforum.de)… 142.132.203.155, 2a01:4f8:261:4fe1::2
    Verbindungsaufbau zu debianforum.de (debianforum.de)|142.132.203.155|:443 … verbunden.
    HTTP-Anforderung gesendet, auf Antwort wird gewartet … 400 Bad Request
    
  • HTTPS-Request auf Port 80 bzw. an HTTP-Server

    Code: Alles auswählen

    $ wget --spider https://debianforum.de:80
    Spider-Modus eingeschaltet. Es wird geprüft, ob die Datei auf dem Server existiert.
    --2024-10-02 23:50:37--  https://debianforum.de:80/
    Auflösen des Hostnamens debianforum.de (debianforum.de)… 142.132.203.155, 2a01:4f8:261:4fe1::2
    Verbindungsaufbau zu debianforum.de (debianforum.de)|142.132.203.155|:80 … verbunden.
    GnuTLS: Ein unerwartetes TLS-Paket wurde empfangen.
    Es ist nicht möglich, eine SSL-Verbindung herzustellen.
    

Lockslay
Beiträge: 224
Registriert: 22.08.2002 17:51:19
Kontaktdaten:

Re: reverse proxy Bad Gateway

Beitrag von Lockslay » 07.10.2024 10:03:01

Hallo zusammen,

ich danke euch für die Hilfe und die gute Erklärung.

Ich habe jetzt in der /etc/nginx/sites-availible/sitename-443.conf

Code: Alles auswählen

Das so eingetragen 

proxy_pass http://domainname.de:80;
Damit wird die Seite weitergeleitet bzw. auf den Nginx weitergeleitet.
Von RP zum nginx habe ich kein ssl
Besser habe ich es nicht hinbekommen.

Lockslay
Beiträge: 224
Registriert: 22.08.2002 17:51:19
Kontaktdaten:

Re: reverse proxy Bad Gateway

Beitrag von Lockslay » 11.10.2024 17:09:46

Hallo zusammen,

da ich schon mal bei Thema bin und ich hier bereits nette Hilfe gefundne habe, wollte ich eine weitere Domain einrichten die dann auf einen weiteren Virtuellen Host auf dem Webserver verweist.

Ich habe auf Debian einen Reverse Proxy laufen der auf einen Webserver mit nginx verweist.

Auf dem Reverse Proxy habe ich mir eine template Datei 443-conf und eine 80-conf angelegt
Die template.dyndns.org-443.confhabe ich hier veröffentlicht:
Meine Frage, wird das was ich auf dem RP und dem Webserver so machen würde so klappen oder seht ihr hier irgendwelche Fehler die ich machen würde?

Code: Alles auswählen

#
# HTTPS server configuration for TEMPLATE.dyndns.org;
#
# This file is a template. Replace TEMPLATE.dyndns.org with the desired.
# hostname. Don't forget to adjust "proxy_pass", too.
#
#
# Created on:		2021-08-06
# Last modified on:	2021-08-06
#

server {
        listen 443;

        server_name TEMPLATE.dyndns.org;

        root /var/www/sites/TEMPLATE.dyndns.org;

        access_log   /var/log/nginx/TEMPLATE.dyndns.org-443-access.log;
        error_log    /var/log/nginx/TEMPLATE.dyndns.org-443-error.log;

        # With Nginx v1.15.2 the "ssl" directive is deprecated, this version is 1.14.2
        ssl                  on;

        ssl_certificate /etc/letsencrypt/live/TEMPLATE.dyndns.org/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/TEMPLATE.dyndns.org/privkey.pem;

        include /etc/nginx/snippets/include.ssl-common;

        # when serving user-supplied content, include a X-Content-Type-Options: nosniff header along with the Content-Type: header,
        # to disable content-type sniffing on some browsers.
        # https://www.owasp.org/index.php/List_of_useful_HTTP_headers
        # currently suppoorted in IE > 8 http://blogs.msdn.com/b/ie/archive/2008/09/02/ie8-security-part-vi-beta-2-update.aspx
        # http://msdn.microsoft.com/en-us/library/ie/gg622941(v=vs.85).aspx
        # 'soon' on Firefox https://bugzilla.mozilla.org/show_bug.cgi?id=471020
        add_header X-Content-Type-Options nosniff;

        # This header enables the Cross-site scripting (XSS) filter built into most recent web browsers.
        # It's usually enabled by default anyway, so the role of this header is to re-enable the filter for.
        # this particular website if it was disabled by the user.
        # https://www.owasp.org/index.php/List_of_useful_HTTP_headers
        add_header X-XSS-Protection "1; mode=block";

        # The following option enables or disables emitting nginx version on error pages and in the "Server" response header field:
        server_tokens off;

        location /nginx_status {
                stub_status on;
                access_log on;

                allow 127.0.0.1;
                deny all;
        }

        location / {

                access_log /var/log/nginx/TEMPLATE.dyndns.org-443-access-upstream.log;
                error_log /var/log/nginx/TEMPLATE.dyndns.org-443-error-upstream.log;

                # Extended buffer sizes
                proxy_buffers 8 16k;
                proxy_buffer_size 32k;

                proxy_pass https://127.0.0.1:443;
                # proxy_ssl_verify SHOULD be set of "on" later
                proxy_ssl_verify off;
                proxy_set_header X-Forwarded-For $remote_addr;
                proxy_set_header X-Forwarded-Proto $scheme;
                proxy_set_header Host $host;

                allow all;
                deny all;
        }

} # of server
Die Seiten anlegen:

Code: Alles auswählen

cp /etc/nginx/sites-available/template.dyndns.org-80.conf /etc/nginx/sites-available/wunschdomain.de-80.conf

cp /etc/nginx/sites-available/template.dyndns.org-443.conf /etc/nginx/sites-available/wunschdomain.de-443.conf
In der Datei die Domain umschreiben lassen

Code: Alles auswählen

sed -i 's/TEMPLATE.dyndns.org/wunschdomain.de/g' /etc/nginx/sites-available/wunschdomain.de-80.conf

sed -i 's/TEMPLATE.dyndns.org/wunschdomain.de/g' /etc/nginx/sites-available/wunschdomain.de-443.conf
Link setzten

Code: Alles auswählen

ln -s /etc/nginx/sites-available/wunschdomain.de-80.conf /etc/nginx/sites-enabled/wunschdomain.de-80.conf
Inhalt vom template, was eine index.html ist ins neue sites kopieren

Code: Alles auswählen

cp -aR /var/www/sites/template.dyndns.org /var/www/sites/wunschdomain.de
Name der neue Seite umchreiben lassen

Code: Alles auswählen

sed -i 's/TEMPLATE.dyndns.org/wunschdomain.de/g' /var/www/sites/template.dyndns.org/index.html
Nginx testen und dann restart
nginx -t
systemctl restart nginx.service; systemctl -l status nginx.service
Das Zertifikat testen lassen

Code: Alles auswählen

certbot certonly --dry-run --webroot --agree-tos --email meinemail@adresse.de -d wunschdomain.de -w /var/www/sites/wunschdomain.de
Wenn Test OK dann weiter
certbot certonly --webroot --agree-tos --email meinemail@adresse.de -d wunschdomain.de -w /var/www/sites/wunschdomain.de
Link setzten lassen

Code: Alles auswählen

ln -s /etc/nginx/sites-available/wunschdomain.de-443.conf /etc/nginx/sites-enabled/wunschdomain.de-443.conf

Code: Alles auswählen

nano /etc/nginx/sites-enabled/wunschdomain.de-443.conf
Hier würde ich die Domain eintragen
Nginx testen und restart

Code: Alles auswählen

nginx -t
systemctl restart nginx.service; systemctl -l status nginx.service
Webserver:
cd /etc/nginx/sites-available/
cp blog.intern.fahl-secure.de-80.conf wunschdomain.intern.de-80.conf
nano wunschdomain.intern.de-80.conf

Code: Alles auswählen

server {
listen 80;
server_name wunschdomain.de;

    root /var/www/sites/wunschdomain.intern.de;
    
    access_log   /var/log/nginx/wunschdomain.intern.de-80-access.log;
    error_log    /var/log/nginx/wunschdomain.intern.de-80-error.log;

    # The following option enables or disables emitting nginx version on error pages and in the "Server" response header field:
    server_tokens off;

    location / {

            allow all;
            deny all;
    }
} # of server
ln -s /etc/nginx/sites-available/wunschdomain.intern.de-80.conf /etc/nginx/sites-enabled/
nginx -t

systemctl restart nginx
Danach sollte nachmeiner Vorstellung die neuen wunschdomain.de erreichbar sein und auf den Webserver wieterleiten und die Seite die im /var/www/sites/wunschdomain.intern.de Ordner liegt abrufen.

Würde mch sehr über eine Rückmeldung und verbesserungen freuen.

VG Lockslay

Antworten