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 www.empresa.com.br/serv1 ele irá solicitar o serviço em http://192.168.0.22:80/serv1/ 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 www.empresa.com.br 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!

Aqui termino minha publicação do artigo e espero que isso possa ajudar alguém como tem me ajudado até hoje. Caso alguém tenha alguma dúvida, estarei a disposição para poder exclarecê-las.

Abraço a todos! 30/12/2003