Proxy reverso com Apache2
vagnerfonseca
Hospedar um site não é mais coisa de provedor de internet, muita gente tem banda larga em casa, se não tem ip fixo usa um dns dinâmico. Empresas tem links com ips disponíveis e preferem ter o controle do seu site, ou até em vez de ter apenas a hospedagem eles preferem ter o servidor dedicado para o serviço.
A questão em ter o controle do servidor é também ter a responsabilidade pela segurança dos sites, além do mod_security (que abordaremos mais oportunamente) uma etapa de melhoria na segurança é colocar mais uma camada entre quem acessa e o servidor Web.
Essa camada serviria para não deixar os clientes acessarem diretamente o servidor, não ter acesso aos diretórios onde estão as páginas e caso o servidor fosse atacado, apenas o proxy seria afetado mantendo o servidor principal íntegro, sem acesso externo, mas íntegro.
Nosso cenário é o seguinte:
Um servidor Web(podem ser mais) com todas as paginas da empresa e com os acessos de banco de dados configurados, com seus respectivos virtualhosts que atendem pelos nomes: www.cooperati.local (site principal), cursos.cooperati.local (sites com os cursos), videocasts.cooperati.local (sites dos videos).
Esses sites são apenas internos e precisam ser acessados pela internet nos seguintes endereços: 82c.bd8.myftpupload.com, cursos.82c.bd8.myftpupload.com, videocasts.82c.bd8.myftpupload.com.
No servidor (ou servidores) web não precisa ser alterado nada em suas configurações, apenas a programação não deve fazer apenas referência a endereços de IP internos, pois isso pode causar erro no cliente ao tentar buscar IP da rede interna do servidor.
No servidor Proxy devemos fazer o seguinte:
Primeiro instale o Apache2:
root # apt-get install apache2
Habilite os módulos necessários:
root # a2enmod proxy proxy_balancer proxy_connect proxy_html proxy_http
OBS: Pode ser que você não use todos os tipos de recursos fornecidos habilite os módulos mesmo assim, logo você vai querer mais recursos e eles já estão lá ;-).
Basta agora criar os arquivos que fazem o redirecionamento dos domínios:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | root # vi /etc/apache2/sites-available/www-cooperati ProxyVia On <virtualHost *:80> ServerName 82c.bd8.myftpupload.com ProxyPreserveHost On ProxyRequests Off ProxyPass / http://www.cooperati.local/ ProxyPassReverse / http://www.cooperati.local/ ProxyPass /includes http://www.cooperati.local/includes ProxyPassReverse /includes http://www.cooperati.local/includes Redirect Permanent / http://www.cooperati.local/ <ifModule mod_deflate.c> AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript application/x-javascript application/xml application/xhtml+xml "application/x-javascript \n\n" "text/html \n\n" DeflateCompressionLevel 9 </ifModule> </virtualHost> |
Onde:
ProxyVia On – Habilita o proxy nesse domínio
ServerName – Endereço de vem na URL e que vai ser usado para proxy do endereço interno.
ProxyPreserveHost – Em ON ele vai preservar o endereço do host que está fazendo o proxy e não daquele da diretiva ProxyPass
ProxyRequests – Em Off evita que usem seu servidor para relay de spammers 🙂
ProxyPass – O endereço do site após URL (/ raiz do site), e depois em qual servidor e porta está o site
ProxyPassReverse (a mesma coisa de proxy pass)
Módulo deflate é usado para comprimir as páginas, ele negocia com os clientes uma compressão e envia os dados compactados gerando muito menos tráfego na rede 😉
Depois é só criar os arquivos, seguindo o mesmo padrão para os outros domínios:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | root # vi /etc/apache2/sites-available/cursos-cooperati ProxyVia On <virtualHost *:80> ServerName cursos.82c.bd8.myftpupload.com ProxyPreserveHost On ProxyRequests Off ProxyPass / http://cursos.cooperati.local/ ProxyPassReverse / http://cursos.cooperati.local/ ProxyPass /includes http://cursos.cooperati.local/includes ProxyPassReverse /includes http://cursos.cooperati.local/includes Redirect Permanent / http://cursos.cooperati.local/ <ifModule mod_deflate.c> AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript application/x-javascript application/xml application/xhtml+xml "application/x-javascript \n\n" "text/html \n\n" DeflateCompressionLevel 9 </ifModule> </virtualHost> |
Agora do site dos famosos videocasts :
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | root # vi /etc/apache2/sites-available/videocasts-cooperati ProxyVia On <virtualHost *:80> ServerName videocasts.82c.bd8.myftpupload.com ProxyPreserveHost On ProxyRequests Off ProxyPass / http://videocasts.cooperati.local/ ProxyPassReverse / http://videocasts.cooperati.local/ ProxyPass /includes http://videocasts.cooperati.local/includes ProxyPassReverse /includes http://videocasts.cooperati.local/includes Redirect Permanent / http://videocasts.cooperati.local/ <ifModule mod_deflate.c> AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript application/x-javascript application/xml application/xhtml+xml "application/x-javascript \n\n" "text/html \n\n" DeflateCompressionLevel 9 </ifModule> </virtualHost> |
Agora habilite os sites:
root # a2ensite www-cooperati cursos-cooperati videocasts-cooperati
Feito isso vamos reiniciar o Apache ( poderíamos apenas fazer reload, mas como habilitamos os módulos devemos fazer o reinício do serviço):
root # service apache2 restart
Pronto, agora basta colocar no seu browser o endereço de internet do seu site que o proxy reverso do apache fará o redirecionamento para o servidor interno.
Não se esqueçam de assinar o site, curtir a página do Facebook e votar no CooperaTI no TopBlog
Esse meu servidor web principal ( não o do proxy) pode ser um IIS da vida? Esse proxy pode ser o mesmo utilizado para proxy cache, sarg e outras ferramentas?
Bruno,
O servidor web interno pode ser qualquer um (IIS, apache2, nginx, lighthttpd,etc). Esse proxy reverso feito com apache2 pode conviver em paz com um squid, por exemplo, desde que a máquina suporte esse nível de escrita em disco.
Caramba uma vez tinha lido um artigo sobre esse assunto no Viva o Linux e o cara voou tando que acabei me perdendo, mais uma vez ótimo post Vagner. =)
Eu ainda penso que vale mais a pena se contratar uma conta em um servidor mesmo para não ter dor de cabeça com: Segurança, backup, etc. Mais para servidor de aplicação, acesso local é mesmo a melhor escolha.
Sucessos.
Como ficaria no Debian 9?