☰

Actualizar:

tag-icon • tag-icon reverse-proxy
Actualizar:

Tengo un servidor doméstico de matriz y una aplicación web Django ubicada en máquinas virtuales en 192.168.81y 192.168.83respectivamente. El servidor doméstico está construido conimplementación-ansible-de-matrix-dockery se ejecuta en nginx. Obtiene y renueva certificados SSL a través deTraefikconvamos a cifrar.

La aplicación web utiliza su propio certificado Let's Encrypt. Aunque puedo conseguir que funcionen de forma independiente, tengo problemas para que funcionen juntos, en los mismos puertos 80 y 443.

Después de configurar el proxy inverso en la aplicación web para desviar el tráfico de su dominio, así:

        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/

Yo obtengo:

[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/

Actualizar:

Dado que ejecutar los dos servidores en el mismo puerto es casi seguro que arruinaría la certificación SSL (a menos que queramos que compartan el mismo certificado y usen un proxy inverso en un servidor separado para redirigir el tráfico de los dominios separados a sus respectivos servidores internos). , Me gustaríautilizar puertos distintos de 80 y 443para alojar mi aplicación web.

¿Cómo debo hacer esto?

Respuesta1

Esto se debe a que el certificado SSL/TLS presentado por el backend, 192.168.1.83:443, no es válido porque para un certificado válido siempre se necesita un nombre de dominio.

Creo que si donde abrirhttps://192.168.1.83/en un navegador (dado que, por supuesto, se puede acceder a la IP 192.168.1.83), aparecerá la advertencia "Conexión no segura".

Tus opciones son (aproximadamente en orden de dificultad):

  1. Confíe ciegamente en la red backend y use SSL solo en el proxy de reenvío, conectándose a los backends a través de http simple. Si su proxy de reenvío de Apache se ejecuta en la misma máquina que esas máquinas virtuales y usted controla tanto el proxy de reenvío como las máquinas virtuales, esto es lo que yo haría.
  2. No confíe en la red backend y cifre tanto en el frontend como en el backend, entonces deberá hacerlo
    • use nombres de dominio válidos para que el certificado se conecte al backend (potencialmente configurando la IP para el dominio en su archivo de hosts), asegúrese de que el certificado sea válido y se renueve
    • establezca la confianza en los certificados explícitamente para esta conexión en la configuración de Apache
    • configure su propia CA para los servicios backend y configúrela como confiable en el proxy directo (¡pero tenga en cuenta que fácilmente se adentrará profundamente en la zona de peligro una vez que maneje su propia CA!)
    • No recomendaría configurar el proxy de reenvío para conectarse a través de SSL sin validar adecuadamente el certificado (por ejemplo, deshabilitar SSLProxy*las opciones) y en su lugar optar por la Opción 1 cuando la red backend sea confiable y una de las tres anteriores si no.
  3. Cifre solo en el backend y use el equilibrio de carga SNI en lugar de su proxy de reenvío Apache para reenviar el tráfico https a su backend sin volver a cifrarlo (en mi opinión, es una configuración más avanzada que la opción 1 y no sé si Apache es adecuado para esta aplicación).

información relacionada