☰

Aktualisieren:

tag-icon • tag-icon reverse-proxy django
Aktualisieren:

Ich habe eine Django-Webanwendung, die die externen Ports 80 und 443 mit einem anderen Server teilt. localhostFunktioniert ohne Reverse-Proxy einwandfrei, aber wenn dieser aktiviert ist, treten alle möglichen Fehler auf.

Wie lässt sich ein Reverse-Proxy ordnungsgemäß betreiben?

reverse-proxy.conf:

      # SSL Certificate and other SSL configurations
      SSLProxyEngine on
      ProxyRequests on
      SSLProxyVerify require 
      SSLProxyCheckPeerCN on
      SSLProxyCheckPeerName on
      SSLProxyCheckPeerExpire on
      ProxyPreserveHost on
      RequestHeader set X-Forwarded-Proto https

      # Reverse Proxy Configuration
      ProxyPass "/" "https://192.168.1.83/"
      ProxyPassReverse "/" "https://192.168.1.83/"

      # Additional SSL configurations if needed

Ich leite alles httpum httpsund füge den obigen Proxy in meine SSL-HTTPS-Konfigurationsdatei ein. Die Site läuft normalohnedie Einbindung (also wann Include .../reverse-proxy.confauskommentiert ist). Wenn Reverse Proxy eingebunden ist, erhalte ich:

[Thu Jan 18 07:09:39.835368 2024] [ssl:error] [pid 46505:tid 133251102926528] [remote 192.168.1.83:443] AH02039: Certificate Verification: Error (20): unable to get local issuer certificate
[Thu Jan 18 07:09:39.835470 2024] [ssl:error] [pid 46505:tid 133251102926528] [remote 192.168.1.83:443] AH02040: Certificate Verification: Certificate Chain too long (chain has 2 certificates, but maximum allowed are only 1)
[Thu Jan 18 07:09:39.835773 2024] [proxy:error] [pid 46505:tid 133251102926528] (20014)Internal error (specific information not available): [client 119.74.38.81:51224] AH01084: pass request body failed to 192.168.1.83:443 (192.168.1.83), referer: https://acupunctureclassique.duckdns.org/
[Thu Jan 18 07:09:39.835832 2024] [proxy:error] [pid 46505:tid 133251102926528] [client 119.74.38.81:51224] AH00898: Error during SSL Handshake with remote server returned by /login/, referer: https://acupunctureclassique.duckdns.org/
[Thu Jan 18 07:09:39.835861 2024] [proxy_http:error] [pid 46505:tid 133251102926528] [client 119.74.38.81:51224] AH01097: pass request body failed to 192.168.1.83:443 (192.168.1.83) from 119.74.38.81 (), referer: https://acupunctureclassique.duckdns.org/

Am Frontend:

Proxy Error
The proxy server could not handle the request

Reason: Error during SSL Handshake with remote server

Apache/2.4.58 (Ubuntu) Server at acupunctureclassique.duckdns.org Port 443

Aktualisieren:

apachectl -S

VirtualHost configuration:
*:443                  acupunctureclassique.duckdns.org (/etc/apache2/sites-enabled/acu-le-ssl.conf:2)
*:80                   acupunctureclassique.duckdns.org (/etc/apache2/sites-enabled/acu.conf:1)
ServerRoot: "/etc/apache2"
Main DocumentRoot: "/var/www/html"
Main ErrorLog: "/var/log/apache2/error.log"
Mutex ssl-stapling: using_defaults
Mutex proxy: using_defaults
Mutex ssl-cache: using_defaults
Mutex default: dir="/var/run/apache2/" mechanism=default 
Mutex watchdog-callback: using_defaults
Mutex rewrite-map: using_defaults
Mutex ssl-stapling-refresh: using_defaults
PidFile: "/var/run/apache2/apache2.pid"
Define: DUMP_VHOSTS
Define: DUMP_RUN_CFG
User: name="www-data" id=33 not_used
Group: name="www-data" id=33 not_used

Antwort1

Das eigentliche Problem stellte sich hier - nach Diskussionen im Chat - darin heraus, dass der Benutzer Nginx verwendete, um den Datenverkehr an dieselbe Nginx-Instanz umzuleiten, wodurch eine nette Umleitungsschleife entstand, die schließlich zu einer zu großen Header-Fehlermeldung führte.

> ProxyPass "/" "https://192.168.1.83/"

Sie senden Ihren Datenverkehr an https://192.168.1.83. Sie behaupten, dies sei ein von Let's Encrypt ausgestelltes Zertifikat, aber LE wirdniemalsein Zertifikat für ausstellen 192.168.1.83, noch wird eine öffentliche CA ein solches Zertifikat ausstellen. Denken Sie daran, dass eingültigZertifikat ist nicht genug, eshatum mit dem erwarteten Namen übereinzustimmen – in diesem Fall ist das 192.168.1.83. Ihre Protokolle sind diesbezüglich auch ziemlich eindeutig.

Sie haben einige Alternativen:

  1. HTTP verwenden
  2. Verwenden Sie ein selbstsigniertes Zertifikat und sorgen Sie dafür, dass Apache ihm vertraut, indem SieSSLProxyCACertificateRichtlinie.
  3. Verwenden Sie einen gültigen Domänennamen und erwerben Sie ein gültiges Zertifikat für den Domänennamen. Der Domänenname kann zu aufgelöst 192.168.1.83oder zu hinzugefügt werden /etc/hosts, aber ApacheWilleHostname und allgemeiner Name (oder SAN) müssen im Zertifikat übereinstimmen.
  4. DeaktivierenVerifizierung des Namens mittelsSSLProxyCheckPeerName = off
  5. Deaktivieren Sie die Überprüfung mitSSLProxyVerify = none, wodurch die Überprüfung effektiv deaktiviert wird. Dies ist mehr oder weniger gleichbedeutend mit der Verwendung von http...

Antwort2

Um einen Reverse-Proxy zu verwenden, müssen Sie einen virtuellen Host in /etc/apache2/sites-available erstellen. Hier ein Beispiel für eine solche VirtualHost-Konfiguration

<VirtualHost *:80>
    ServerName yourdomain.com
    ServerAlias www.yourdomain.com

    DocumentRoot /path/to/your/django/static/files

    Alias /static/ /path/to/your/django/static/files/
    <Directory /path/to/your/django/static/files>
        Require all granted
    </Directory>

    ProxyPass / http://localhost:8000/
    ProxyPassReverse / http://localhost:8000/

    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

<VirtualHost *:443>
    ServerName yourdomain.com
    ServerAlias www.yourdomain.com

    DocumentRoot /path/to/your/django/static/files

    Alias /static/ /path/to/your/django/static/files/
    <Directory /path/to/your/django/static/files>
        Require all granted
    </Directory>

    SSLEngine on
    SSLCertificateFile /path/to/your/ssl/certificate.crt
    SSLCertificateKeyFile /path/to/your/ssl/private.key
    SSLCertificateChainFile /path/to/your/ssl/chainfile.pem

    ProxyPass / https://localhost:8000/
    ProxyPassReverse / https://localhost:8000/

    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

Der https-Teil ist optional. Sie können ihn weglassen, wenn Sie kein https benötigen.

verwandte Informationen