Tweet
Proxy reverse é uma espécie de cluster de máquinas, onde um servidor central utiliza recursos de outros servidores web de sua rede interna. Com um proxy reverse você pode misturar num único site, recursos do Apache em servidor Linux, IIS em Windows 2k, Java em Jakarta Tomcat, etc.
Por: Fabiano S. Ricardo
O que vem a ser um proxy reverse
O que vem a ser necessariamente um Proxy Reverse?
Imagine que você tenha uma máquina Linux rodando o Apache como servidor de aplicações web com páginas em HTML que pode ser facilmente acessado por qualquer pessoa de qualquer lugar.
Bom, suponhamos que você tem dois servidores Windows 2000 Server rodando na rede interna com IPs não roteáveis, um rodando aplicações ASP com o Serviço IIS (Internet Information Service) e outro rodando aplicações Java, por exemplo o Jakarta - TomCat. Ambos acessando um bando de dados robusto do tipo Oracle ou outro banco qualquer.
Só que essas máquinas só conseguem responder por Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar... ou Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar..., ou seja, somente as máquinas da sua rede interna poderão navegar na aplicação e você não tem nenhum ip verdadeiro para estar delegando a essas máquinas para poder torná-las acessíveis para a internet.
Aí entra a jogada o Proxy Reverse! O Proxy Reverse pode ser entendido também como Cluster Web, ou seja, uma máquina principal recebe a solicitação e essa máquina tem por objetivo solicitar o serviço de outra máquina. Não entenda como redirecionamento e sim como troca de processamento, sendo que o processamento estará sendo dividido, ou seja, uma estará postando as informações e a outra estará fornecendo o serviço.
Configurando o Apache para o funcionamento do proxy
Passei um bom tempo estudando o funcionamento desse serviço de Proxy Reverse, pois eu não conhecia ninguém que já tivesse feito isso, porém tive o auxílio de um grande amigo e professor chamado Ulisses T.V. Guedes (responsável pela área de redes do Instituto Nacional de Pesquisa Espaciais) e aqui deixo meus votos de agradecimentos à ele.
No meu caso utilizei o Apache 1.3.27 instalado num Slackware 8.1. As aplicações envolvidas são:
* Windows 2000 Server rodando o IIS com páginas ASP;
* Windows 2000 Server rodando o Jakarta TomCat da Apache.
Suponhamos que esses 2 Servidores Windows já estão configurados para rodar, só que com IPs não roteáveis, ou seja, somente na rede interna.
No caso, somente o Apache que está rodando no Slackware tem o domínio válido e pode ser acessado. Chamaremos o domínio de Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar... para o exemplo.
Como sou do tipo que gosto de fazer tudo na unha, tive que baixar o pacote .tar.gz do Apache, descompactar e compilar. Vamos a receita do bolo!
Os seguintes pacotes foram utilizados:
* apache_1.3.27.tar.gz
* mod_ssl-2.8.14-1.3.27.tar.gz
* php-4.3.4RC2.tar.gz
* openssl-0.9.6i.tar.gz
Vou ser bonzinho e explicar todos os passos desde a instalação do Apache completo até.... ;-)
NOTA: vou partir do princípio que você já fez o download dos pacotes, que podem ser facilmente encontrados a partir do site de busca Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar....
Primeiro passo, descompacte todos os pacotes num diretório qualquer. No meu caso, escolhi /usr/local/src e lá coloquei os arquivos:
# cd /usr/local/src
# tar -zxvf apache_1.3.27.tar.gz
# tar -zxvf mod_ssl-2.8.14-1.3.27.tar.gz
# tar -zxvf php-4.3.4RC2.tar.gz
# tar -zxvf openssl-0.9.6i.tar.gz
Comece a instalação pelo PHP:
# cd php-4.3.RC2
# ./configure --with-apache=../apache_1.3.27
# make
# make install
Agora vá para o diretório do OpenSSL:
# cd ../Openssl-0.9.6i
# ./config
# make
# make install
Agora o ModSSL:
# cd ../mod_ssl-2.8.14-1.3.27
# ./configure --with-apache=../apache_1.3.27 --with-ssl=../openssl-0.9.6i
Agora o Apache:
# ./configure --with-prefix=/usr/local/apache --with-bindir=/usr/local/bin --with-sbindir=/usr/local/sbin --enable-module=ssl --enable-module=proxy --enable-shared=proxy --enable-module-rewrite --enable-shared=rewrite --activate-module=src/modules/libphp4.a
# make
# make certificate
# make install
Falei que gosto de fazer as coisas na mão né? rs. Taí o resultado, porém funciona somente com os módulos que quero.
O importante são os parâmetros --enable-module=proxy e --enable-module=rewrite. No caso de instalações por RPM tipo RedHat, esses módulos vem ativados por padrão, bastando apenas desativar na configuração do httpd.conf o que você não deseja carregar.
Para finalizar a configuração do Apache, volte para o diretório do PHP e copie o arquivo php.ini-dist para /usr/local/lib/php.ini.
Configurando o proxy reverse para acessar outras máquinas
Após tudo estar funcionando, vá para o diretório do Apache e edite o arquivo de configurações:
# cd /usr/local/apache/conf
# vi httpd.conf
Nele, verifique se as seguintes configurações foram bem sucedidas na instalação:
Esses caras são os responsáveis pelo funcionamento do Proxy Reverse. Caso esses não estejam declarados, reveja a compilação do seu Apache.
Agora vamos para o que interessa realmente, procure a linha <IfModule mod_proxy.c>, iremos trabalhar com ela agora:
Nessa primeira passagem está acontecendo o seguinte:
O que se refere a ProxyPass /serv1, significa que quando alguém digitar Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar... ele irá solicitar o serviço em Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar... ou seja, o serviço solicitado roda na porta 80 do primeiro servidor na rede interna.
Um detalhe importante é que a primeira solicitação que é o serv1 digitado no Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar... tem que ser idêntica a entrada do servidor da rede interna, ou seja, no primeiro caso é um IIS que está rodando no 192.168.0.22, então no diretório de serviços dele a pasta onde se encontra as páginas ASP tem que se chamar serv1 (nesse exemplo é claro).
Uma vez encontrado, o ProxyPassReverse devolve a solicitação e quem vai postar a tela é o Apache, sendo que ele não precisa ter suporte a ASP, pois quem está processando páginas ASP é o Windows 2000. Isso forma um cluster, as duas máquinas estão processando as informações e deixando o serviço bem mais rápido.
A diretiva <Directory /usr/local/apache/htdocs/serv1> tem que existir, pois o Apache está fazendo de conta que é ele quem é dono do serviço. então você tem que ter criada uma pasta chamada serv1 no seu htdocs do Apache.
No Redirect Permanent estou forçando para que a navegação do servidor Windows 2000 Server utilize a criptografia de SSL criada no Apache, ou seja o Windows 2000 não tem criptografia, então o Apache fornece o serviço de criptografia.
Continuando dentro da tag <IfModule mod_proxy.c>, vamos ao exemplo de configuração para o segundo servidor:
Essa outra diretiva está acionando o outro Windows 20000, o que roda o Jakarta TomCat. O procedimento é quase idêntico ao que expliquei acima, sendo que nesse caso o AllowCONNECT 443 é utilizado porque além da criptografia do Apache, o Jakarta também está criptografado, então nesse caso os dois servidores estão conversando em criptografia.
Em todo o caso o Jakarta não precisaria estar criptografado, mas fiz uns testes com ele e percebi que se os dois estiverem criptografado, tenho que usar essa diretiva.
E por fim:
Isso serve para a troca de cache e é extremamente importante, dependendo de quantas requisições seu servidor interno tiver, você tem que alterar esse números ai. Caso queira saber mais a fundo consulte a documentação do Apache.
Finalmente, pronto!
Fonte: VivaoLinux
Postado Por: RedDeviL
E por fim:
Por: Fabiano S. Ricardo
O que vem a ser um proxy reverse
O que vem a ser necessariamente um Proxy Reverse?
Imagine que você tenha uma máquina Linux rodando o Apache como servidor de aplicações web com páginas em HTML que pode ser facilmente acessado por qualquer pessoa de qualquer lugar.
Bom, suponhamos que você tem dois servidores Windows 2000 Server rodando na rede interna com IPs não roteáveis, um rodando aplicações ASP com o Serviço IIS (Internet Information Service) e outro rodando aplicações Java, por exemplo o Jakarta - TomCat. Ambos acessando um bando de dados robusto do tipo Oracle ou outro banco qualquer.
Só que essas máquinas só conseguem responder por Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar... ou Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar..., ou seja, somente as máquinas da sua rede interna poderão navegar na aplicação e você não tem nenhum ip verdadeiro para estar delegando a essas máquinas para poder torná-las acessíveis para a internet.
Aí entra a jogada o Proxy Reverse! O Proxy Reverse pode ser entendido também como Cluster Web, ou seja, uma máquina principal recebe a solicitação e essa máquina tem por objetivo solicitar o serviço de outra máquina. Não entenda como redirecionamento e sim como troca de processamento, sendo que o processamento estará sendo dividido, ou seja, uma estará postando as informações e a outra estará fornecendo o serviço.
Configurando o Apache para o funcionamento do proxy
Passei um bom tempo estudando o funcionamento desse serviço de Proxy Reverse, pois eu não conhecia ninguém que já tivesse feito isso, porém tive o auxílio de um grande amigo e professor chamado Ulisses T.V. Guedes (responsável pela área de redes do Instituto Nacional de Pesquisa Espaciais) e aqui deixo meus votos de agradecimentos à ele.
No meu caso utilizei o Apache 1.3.27 instalado num Slackware 8.1. As aplicações envolvidas são:
* Windows 2000 Server rodando o IIS com páginas ASP;
* Windows 2000 Server rodando o Jakarta TomCat da Apache.
Suponhamos que esses 2 Servidores Windows já estão configurados para rodar, só que com IPs não roteáveis, ou seja, somente na rede interna.
No caso, somente o Apache que está rodando no Slackware tem o domínio válido e pode ser acessado. Chamaremos o domínio de Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar... para o exemplo.
Como sou do tipo que gosto de fazer tudo na unha, tive que baixar o pacote .tar.gz do Apache, descompactar e compilar. Vamos a receita do bolo!
Os seguintes pacotes foram utilizados:
* apache_1.3.27.tar.gz
* mod_ssl-2.8.14-1.3.27.tar.gz
* php-4.3.4RC2.tar.gz
* openssl-0.9.6i.tar.gz
Vou ser bonzinho e explicar todos os passos desde a instalação do Apache completo até.... ;-)
NOTA: vou partir do princípio que você já fez o download dos pacotes, que podem ser facilmente encontrados a partir do site de busca Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar....
Primeiro passo, descompacte todos os pacotes num diretório qualquer. No meu caso, escolhi /usr/local/src e lá coloquei os arquivos:
# cd /usr/local/src
# tar -zxvf apache_1.3.27.tar.gz
# tar -zxvf mod_ssl-2.8.14-1.3.27.tar.gz
# tar -zxvf php-4.3.4RC2.tar.gz
# tar -zxvf openssl-0.9.6i.tar.gz
Comece a instalação pelo PHP:
# cd php-4.3.RC2
# ./configure --with-apache=../apache_1.3.27
# make
# make install
Agora vá para o diretório do OpenSSL:
# cd ../Openssl-0.9.6i
# ./config
# make
# make install
Agora o ModSSL:
# cd ../mod_ssl-2.8.14-1.3.27
# ./configure --with-apache=../apache_1.3.27 --with-ssl=../openssl-0.9.6i
Agora o Apache:
# ./configure --with-prefix=/usr/local/apache --with-bindir=/usr/local/bin --with-sbindir=/usr/local/sbin --enable-module=ssl --enable-module=proxy --enable-shared=proxy --enable-module-rewrite --enable-shared=rewrite --activate-module=src/modules/libphp4.a
# make
# make certificate
# make install
Falei que gosto de fazer as coisas na mão né? rs. Taí o resultado, porém funciona somente com os módulos que quero.
O importante são os parâmetros --enable-module=proxy e --enable-module=rewrite. No caso de instalações por RPM tipo RedHat, esses módulos vem ativados por padrão, bastando apenas desativar na configuração do httpd.conf o que você não deseja carregar.
Para finalizar a configuração do Apache, volte para o diretório do PHP e copie o arquivo php.ini-dist para /usr/local/lib/php.ini.
Configurando o proxy reverse para acessar outras máquinas
Após tudo estar funcionando, vá para o diretório do Apache e edite o arquivo de configurações:
# cd /usr/local/apache/conf
# vi httpd.conf
Nele, verifique se as seguintes configurações foram bem sucedidas na instalação:
Código:
LoadModule rewrite_module libexec/mod_rewrite.so
LoadModule php4_module libexec/libphp4.so -> esse é apenas para o PHP
LoadModule proxy_module libexec/libproxy.so
AddModule mod_proxy.c
AddModule mod_rewrite.c
Agora vamos para o que interessa realmente, procure a linha <IfModule mod_proxy.c>, iremos trabalhar com ela agora:
Código:
<IfModule mod_proxy.c>
ProxyRequests Off -> deixe essa linha como Off, já tive problema com ela
ProxyPass /serv1/ http://192.168.0.22:80/serv1/
ProxyPassReverse /serv1/ http://192.168.0.22:80/serv1/
<Directory /usr/local/apache/htdocs/serv1>
Order Allow,deny
Allow from all
</Directory>
Redirect Permanent /serv1 https://www.empresa.com.br/serv1/
O que se refere a ProxyPass /serv1, significa que quando alguém digitar Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar... ele irá solicitar o serviço em Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar... ou seja, o serviço solicitado roda na porta 80 do primeiro servidor na rede interna.
Um detalhe importante é que a primeira solicitação que é o serv1 digitado no Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar... tem que ser idêntica a entrada do servidor da rede interna, ou seja, no primeiro caso é um IIS que está rodando no 192.168.0.22, então no diretório de serviços dele a pasta onde se encontra as páginas ASP tem que se chamar serv1 (nesse exemplo é claro).
Uma vez encontrado, o ProxyPassReverse devolve a solicitação e quem vai postar a tela é o Apache, sendo que ele não precisa ter suporte a ASP, pois quem está processando páginas ASP é o Windows 2000. Isso forma um cluster, as duas máquinas estão processando as informações e deixando o serviço bem mais rápido.
A diretiva <Directory /usr/local/apache/htdocs/serv1> tem que existir, pois o Apache está fazendo de conta que é ele quem é dono do serviço. então você tem que ter criada uma pasta chamada serv1 no seu htdocs do Apache.
No Redirect Permanent estou forçando para que a navegação do servidor Windows 2000 Server utilize a criptografia de SSL criada no Apache, ou seja o Windows 2000 não tem criptografia, então o Apache fornece o serviço de criptografia.
Continuando dentro da tag <IfModule mod_proxy.c>, vamos ao exemplo de configuração para o segundo servidor:
Código:
ProxyPass /clijava/ http://192.168.0.20/clijava/
ProxyPassReverse /clijava/ http://192.168.0.20/clijava/
AllowCONNECT 443
<Directory /usr/local/apache/htdocs/clijava>
Order Allow,deny
Allow from all
</Directory>
Redirect Permanent /clijava https://www.empresa.com.br/clijava/
</IfModule>
Em todo o caso o Jakarta não precisaria estar criptografado, mas fiz uns testes com ele e percebi que se os dois estiverem criptografado, tenho que usar essa diretiva.
E por fim:
Código:
ProxyVia On
<IfModule mod_disk_cache.c>
CacheRoot "/usr/local/apache/proxy"
CacheSize 5
CacheGcInterval 4
CacheMaxExpire 24
CacheLastModifiedFactor 0.1
CacheDefaultExpire 1
</IfModule>
Finalmente, pronto!
Fonte: VivaoLinux
Postado Por: RedDeviL
E por fim: