☰

Redirecionamento de subdomínio Apache definido para outro subdomínio

tag-icon • tag-icon apache-2.4 subdomain mod-proxy
Redirecionamento de subdomínio Apache definido para outro subdomínio

Estou tentando configurar dois subdomínios, for ae bin domain.com. Eu uso dois arquivos .conf, que parecem praticamente iguais com as alterações correspondentes em ServerName e ProxyPass:

<VirtualHost *:80>
        ServerName a.domain.com #This was added as a try for a fix. 
        Redirect permanent /  https://a.domain.com/
</VirtualHost>

<VirtualHost *:443>

        ServerName a.domain.com
        ServerAdmin webmaster@localhost
        DocumentRoot /var/www/html/a

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

        #SSL stuff

        #Proxies

        ProxyPass        /        https://a.domain.com:8444/
        ProxyPassReverse /        https://a.domain.com:8444/
        ProxyPass        /a/      https://a.domain.com:8444/
        ProxyPassReverse /a/      https://a.domain.com:8444/
        ProxyPass        /b/      https://b.domain.com:8445/
        ProxyPassReverse /b/      https://b.domain.com:8445/

</VirtualHost>

Isso está sendo feito em meu ambiente de testes, replicando algo semelhante ao que está atualmente em produção. Em /etc/hosts, adicionei a.domain.come b.domain.coma 127.0.0.1. O DNS em produção possui registros de what a.domain.come b.domain.comare, que é o mesmo IP (também fiz isso na máquina em que estou testando).

Observe também que não estou exibindo nenhum conteúdo de seus diretórios raiz. Acrescentei isso tentando corrigir o problema declarado no título. Porém, existe um html simples em ambos os diretórios.

Qual é o problema real?

Simplesmente, ao tentar a.domain.com, o resultado é o webapp de localhost:8444, como esperado. Ao tentar b.domain.com, o resultado também é localhost:8444, em vez de localhost:8445. Ambos a.confe b.confestão habilitados, e se eu desabilitar a.conf, estou obtendo corretamente localhost:8445. Se eu também tentar like a.domain.com/b, o redirecionamento volta para a.domain.com.

Eu li várias perguntas e tutoriais, e a maioria deles tem algo funcionando como na minha configuração ou adiciona NameVirtualHost, que entendo não ser necessário para minha versão do Apache. Também adicionei um ServerName na porta 80 porque pensei que talvez a solicitação bestivesse sendo correspondida por a.confserem do mesmo IP, mas também não funcionou.

O que estou perdendo aqui? É algo com mod_proxy que pareço estar ignorando? Se possível, gostaria de manter um arquivo por webapp. Obrigado!

Isso está no Ubuntu 18.04.2, Apache 2.4 (mod_proxy e mod_ssl), Tomcat 9. Qualquer outra informação que você desejar, tentarei o meu melhor para entregar.

ATUALIZAR

Tentei com esta configuração também. O mesmo resultado indesejado.

<VirtualHost *:80>
        ServerAlias a.domain.com
        Redirect permanent /  https://a.domain.com/
</VirtualHost>

<VirtualHost *:443>

        ServerName a.domain.com
        ServerAdmin webmaster@localhost

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

        #SSL stuff

        #Proxies

        Redirect /b https://b.domain.com

        <Location />
                ProxyPass               https://localhost:8444/
                ProxyPassReverse        https://localhost:8444/
        </Location>

        <Location /a>
                ProxyPass               https://localhost:8444/
                ProxyPassReverse        https://localhost:8444/
        </Location>

</VirtualHost>

ATUALIZAR

Ok, acabei de encontrar algo muito chato. Se eu entrar com meu navegador para a.domain.comou b.domain.com, ambos resolverão para a.domain.com. Esse é o problema que descrevi originalmente. MAS se try https://a.domain.comou https://b.domain.com, ambos resolverem para o servidor correto: ato 8444e bto 8445.

Como isso é muito frustrante, vou dar uma pausa e analisar isso daqui a pouco.

ATUALIZAR

Depois de uma longa pausa, tentei alguns outros ajustes aleatórios só para ver o que acontecia e mais uma vez nada funcionou como esperado, exceto ao usar HTTPS. Instalei o Postman para ver o que estava sendo enviado na solicitação e descobri que no Postman tanto HTTP quanto HTTPS usam o Host corretamente. Ainda melhor/pior: a resposta real mostra as diferentes páginas de boas-vindas para a.domain.come b.domain.com, o que significa que minhas configurações estão funcionando corretamente quando uso o Postman.

Acho que toda essa provação pode ser apenas um problema de cache, mas meu navegador de teste preferido (Firefox dev ed) está configurado para não armazenar coisas em cache. Verificarei as respostas com curl e com meus outros navegadores.

Responder1

Culpado:A cache.

Em algum momento, a configuração do meu navegador mudou (talvez uma atualização?) E eu tinha mais de 3 GB de cache, incluindo os sites de teste que estava tentando configurar como subdomínios. Caramba.

Depois de limpar o cache, acionou um alerta sobre meu certificado autoassinado ao acessar meus URLs, conforme esperado. Após aceitar os riscos, fui redirecionado para os sites apropriados. Isso usando b.domain.comsem adicionar o protocolo.

Para ter certeza de que estava funcionando, testei em todos os meus outros 7 navegadores (tenho que ter certeza) e curl com e sem o protocolo e os resultados também foram os desejados.

No final a configuração estava ok. Vou postar aqui caso você preciseUm servidor Apache fazendo proxy para instâncias específicas do Tomcat por subdomínio, usando proxy_mod que também redireciona imediatamente da porta 80 para a porta 433.

<VirtualHost *:80>
        ServerName a.domain.com
        Redirect permanent /  https://a.domain.com/
</VirtualHost>

<VirtualHost *:443>
        
        ServerName a.domain.com
        ServerAdmin [email protected]

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

        #SSL stuff

        SSLEngine On
        SSLCertificateFile /etc/ssl/certs/DONT_USE_SELF_SIGNED.pem
        SSLCertificateKeyFile /etc/ssl/private/CERTS_IN_PRODUCTIve.key
        SSLVerifyClient none

        #Proxies
        ProxyRequests Off
        SSLProxyEngine on
        SSLProxyVerify none
        SSLProxyCheckPeerCN off
        SSLProxyCheckPeerName off
        SSLProxyCheckPeerExpire off

        #Redirections
        Redirect /b https://b.domain.com

        <Location />
                ProxyPass               https://localhost:8444/
                ProxyPassReverse        https://localhost:8444/
        </Location>

        <Location /a>
                ProxyPass               https://localhost:8444/
                ProxyPassReverse        https://localhost:8444/
        </Location>

</VirtualHost>

Leve em consideração que as configurações de proxy SSL e SSL são para certificados autoassinados. Leia a documentação relevante de cada um se você implementar isso em ambientes produtivos. Observe também que este é o arquivo de configuração do a.domain.com. O equivalente para b.domain.comé exatamente o mesmo, com o ServerName, ServerAlias, redirecionamentos, localização e porta do localhost apropriados.

informação relacionada