☰

Aktualisieren:

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

Ich habe einen Matrix-Home-Server und eine Django-Web-App auf VMs bei 192.168.81bzw. 192.168.83. Der Home-Server ist gebaut mitMatrix-Docker-Ansible-Bereitstellungund läuft auf nginx. Es erhält und erneuert SSL-Zertifikate überTraefikmitLass uns verschlüsseln.

Die Web-App verwendet ein eigenes Let's Encrypt-Zertifikat. Obwohl ich sie unabhängig voneinander zum Laufen bringen kann und das auch schon geschafft habe, habe ich Probleme, sie zusammen auf denselben Ports 80 und 443 zum Laufen zu bringen.

Richten Sie nach dem Einrichten eines Reverse-Proxys auf der Seite der Web-Anwendung den Datenverkehr von seiner Domäne um, wie folgt:

        SSLEngine On
        SSLCertificateFile /etc/letsencrypt/live/mysite.org/cert.pem
        SSLCertificateKeyFile /etc/letsencrypt/live/mysite.org/privkey.pem
        SSLCertificateChainFile /etc/letsencrypt/live/mysite.org/fullchain.pem

        # Enable SSL Proxy Engine
        SSLProxyEngine On
        ProxyPass / https://192.168.1.83/
        ProxyPassReverse / https://192.168.1.83/

Ich bekomme:

[Wed Jan 17 07:13:21.567813 2024] [core:notice] [pid 33994:tid 125031783462784] AH00094: Command line: '/usr/sbin/apache2'
[Wed Jan 17 07:15:23.409061 2024] [proxy:error] [pid 34272:tid 125031640188608] (20014)Internal error (specific information not available): [client 192.168.1.85:44054] AH01084: pass request body failed to 192.168.1.83:443 (192.168.1.83)
[Wed Jan 17 07:15:23.409180 2024] [proxy:error] [pid 34272:tid 125031640188608] [client 192.168.1.85:44054] AH00898: Error during SSL Handshake with remote server returned by /
[Wed Jan 17 07:15:23.409209 2024] [proxy_http:error] [pid 34272:tid 125031640188608] [client 192.168.1.85:44054] AH01097: pass request body failed to 192.168.1.83:443 (192.168.1.83) from 192.168.1.85 ()
[Wed Jan 17 07:15:23.715825 2024] [proxy:error] [pid 34273:tid 125031648581312] (20014)Internal error (specific information not available): [client 192.168.1.85:44070] AH01084: pass request body failed to 192.168.1.83:443 (192.168.1.83), referer: https://192.168.1.83/
[Wed Jan 17 07:15:23.715945 2024] [proxy:error] [pid 34273:tid 125031648581312] [client 192.168.1.85:44070] AH00898: Error during SSL Handshake with remote server returned by /favicon.ico, referer: https://192.168.1.83/
[Wed Jan 17 07:15:23.715970 2024] [proxy_http:error] [pid 34273:tid 125031648581312] [client 192.168.1.85:44070] AH01097: pass request body failed to 192.168.1.83:443 (192.168.1.83) from 192.168.1.85 (), referer: https://192.168.1.83/

Aktualisieren:

Da das Ausführen der beiden Server auf demselben Port mit ziemlicher Sicherheit die SSL-Zertifizierung beeinträchtigen würde (es sei denn, wir möchten, dass sie dasselbe Zertifikat verwenden und einen Reverse-Proxy auf einem separaten Server verwenden, um den Verkehr von den separaten Domänen auf ihre jeweiligen internen Server umzuleiten), möchte ichVerwenden Sie andere Ports als 80 und 443um meine Web-App zu hosten.

Wie gehe ich dabei vor?

Antwort1

Dies liegt daran, dass das vom Backend vorgelegte SSL/TLS-Zertifikat 192.168.1.83:443 nicht gültig ist, da für ein gültiges Zertifikat immer ein Domänenname erforderlich ist.

Ich glaube, wenn Sie öffnen würdenhttps://192.168.1.83/in einem Browser (vorausgesetzt natürlich, die IP 192.168.1.83 ist erreichbar), würden Sie die Warnung „Verbindung nicht sicher“ erhalten.

Ihre Optionen sind (ungefähr in der Reihenfolge der Schwierigkeit):

  1. Vertrauen Sie blind dem Backend-Netzwerk und verwenden Sie SSL nur auf dem Forward-Proxy, wobei Sie sich über einfaches HTTP mit den Backends verbinden. Wenn Ihr Apache-Forward-Proxy auf derselben Maschine wie diese VMs läuft und Sie sowohl den Forward-Proxy als auch die VMs steuern, würde ich Folgendes tun.
  2. Wenn Sie dem Backend-Netzwerk nicht vertrauen und sowohl das Frontend als auch das Backend verschlüsseln, müssen Sie entweder
    • Verwenden Sie für das Zertifikat gültige Domänennamen, um eine Verbindung zum Backend herzustellen (konfigurieren Sie ggf. die IP für die Domäne in Ihrer Hosts-Datei). Stellen Sie sicher, dass das Zertifikat selbst gültig ist und erneuert wird.
    • Setzen Sie in der Apache-Konfiguration explizit Vertrauen in die Zertifikate für diese Verbindung
    • Richten Sie Ihre eigene Zertifizierungsstelle für die Backend-Dienste ein und konfigurieren Sie sie auf dem Forward-Proxy als vertrauenswürdig (aber seien Sie sich bewusst, dass Sie sich leicht in eine große Gefahrenzone begeben, wenn Sie Ihre eigene Zertifizierungsstelle verwalten!)
    • Ich würde nicht empfehlen, den Forward-Proxy für die Verbindung über SSL zu konfigurieren, ohne das Zertifikat ordnungsgemäß zu validieren (z. B. durch Deaktivieren SSLProxy*von Optionen). Wählen Sie stattdessen Option 1, wenn das Backend-Netzwerk vertrauenswürdig ist, und eine der drei oben genannten Optionen, wenn nicht.
  3. Verschlüsseln Sie nur auf dem Backend und verwenden Sie anstelle Ihres Apache-Forward-Proxys den SNI-Lastausgleich, um den https-Verkehr ohne erneute Verschlüsselung an Ihr Backend weiterzuleiten (meiner Meinung nach ein fortgeschritteneres Setup als Option 1 und ich weiß nicht, ob Apache für diese Anwendung geeignet ist).

verwandte Informationen