☰

Atualizar:

tag-icon • tag-icon reverse-proxy
Atualizar:

Eu tenho um servidor doméstico matricial e um aplicativo da web Django em VMs em 192.168.81e 192.168.83respectivamente. O servidor doméstico é construído commatriz-docker-ansible-deploye roda em nginx. Obtém e renova certificados SSL atravésTraefikcomVamos criptografar.

O aplicativo da web usa um certificado Let's Encrypt próprio. Embora eu consiga fazê-los funcionar de forma independente, estou tendo problemas para fazê-los funcionar juntos, nas mesmas portas 80 e 443.

Depois de configurar o proxy reverso no aplicativo da web para desviar o tráfego de seu domínio, da seguinte forma:

        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/

Eu recebo:

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

Atualizar:

Já que executar os dois servidores na mesma porta quase certamente atrapalharia a certificação SSL (a menos que queiramos que eles compartilhem o mesmo certificado e usem um proxy reverso em um servidor separado para redirecionar o tráfego de domínios separados para seus respectivos servidores internos) , Eu gostaria deuse portas diferentes de 80 e 443para hospedar meu aplicativo da web.

Como devo fazer isso?

Responder1

Isso ocorre porque o certificado SSL/TLS apresentado pelo backend, 192.168.1.83:443, não é válido porque para um certificado válido você sempre precisa de um nome de domínio.

Eu acredito que se você onde abrirhttps://192.168.1.83/em um navegador (dado, é claro, que o IP 192.168.1.83 está acessível), você receberá o aviso "Conexão não segura".

Suas opções são (aproximadamente em ordem de dificuldade):

  1. Confie cegamente na rede de back-end e use SSL apenas no proxy de encaminhamento, conectando-se aos back-ends via http simples. Se o seu proxy de encaminhamento do Apache estiver sendo executado na mesma máquina que essas VMs e você controlar o proxy de encaminhamento e as VMs, é isso que eu faria.
  2. Não confie na rede de back-end e criptografe tanto no front-end quanto no back-end, então você precisa
    • use nomes de domínio válidos para o certificado se conectar ao back-end (potencialmente configurando o IP do domínio em seu arquivo hosts), certifique-se de que o certificado seja válido e seja renovado
    • definir confiança nos certificados explicitamente para esta conexão na configuração do Apache
    • configure sua própria CA para os serviços de back-end e configure-a como confiável no proxy de encaminhamento (mas esteja ciente de que você facilmente entrará profundamente na zona de perigo ao lidar com sua própria CA!)
    • Eu não recomendaria configurar o proxy de encaminhamento para conectar-se via SSL sem validar adequadamente o certificado (por exemplo, desabilitar SSLProxy*opções) e, em vez disso, optar pela Opção 1 quando a rede backend for confiável e uma das três acima, se não for.
  3. Criptografe apenas no back-end e use o balanceamento de carga SNI no lugar do proxy de encaminhamento do Apache para encaminhar o tráfego https para o seu back-end sem recriptografia (na minha opinião, uma configuração mais avançada que a opção 1 e não sei se o apache é adequado para esta aplicação).

informação relacionada