Squid + ipfw + NAT - Ajuda

Oi pessoal

Tudo blz?

tenho um problema que eh o seguinte:

preciso redirecionar todo o meu trafego da porta 80 para 443 (para conexoes com a internet) de forma que quando o usuario digitar http://meusite, ele seja redirecionado para https://meusite.

Estou usando o squid no modo accelerator.

tentei com o ipfw e nat mas nao esta dando certo.

eis minhas regras:

Trafego de entrada

$ipfw_cmd add divert natd tcp from not 10.0.0.0:255.255.240.0 to me 80 via en0 in
$ipfw_cmd add divert natd udp from not 10.0.0.0:255.255.240.0 to me 80 via en0 in

Trafego de saida
$ipfw_cmd add divert natd tcp from not 10.0.0.0:255.255.240.0 to me 80 via en0 out
$ipfw_cmd add divert natd udp from not 10.0.0.0:255.255.240.0 to me 80 via en0 out

regras de nat:

interface en0
dynamic yes
use_sockets yes
redirect_port tcp 192.168.0.73:443 80
redirect_port udp 192.168.0.73:443 80

192.168.0.73 eh o meu ip.

jah tentei inverter os argumentos colocar 443 no lugar de 80 e vice versa, mas nao funciona. Quando aplico estas regras soh o https funciona.

A rede 10.0.0.0 eh onde estao os servidores reais de http e eh a minha rede interna. Eles nao falam https.

O esquema atual esta assim:

_______(http)_________(http)
cliente----------> squid -----------> servidor 1 (2, 3 ...n)

E eu preciso deixa-lo assim:

_______(https)_________(http)
cliente-----------> squid -----------> servidor 1 (2, 3 ...n)

O que estah acontecendo eh que na estrutura anterior (sem as regras dp ipfw e nat), quando um dos servidores respondem pro squid em http (o que eh desejavel) ele repassa para o cliente em http de novo e nao em https que eh o que deve ser.

Lembrando que o cliente esta na internet, o squid tem conexao direta com a internet (na verdade ele esta atras de um firewall, mas nao ha restricoes quanto aos servicos http e https) e tudo isso deve ser transparente pro usuario (cliente).

ufa! acho que eh isso!

Estou usando um Darwin (Mac OS X) (baseado em BSD 4.4).

Se alguem puder me ajudar agradeco.

Valeu!!

[gmlinux]

Sinto informar, o que esta fazendo não funciona, observe o seguinte, o cliente fez uma requisição http, não adianta responder usando protocolo https, é como jogar uma requisição de ftp na porta 80, por exemplo.

A solução é colocar no seu server de páginas, para requisições na porta 80, uma tag html de redirect indicando https://seu.server, isto vai fazer os clientes repetirem a requisição, só que usando o protocolo https, o que por default é feito na 443, e para a porta https fica a página normal.

Ateh aih tudo bem, eu jah tentei fazer isso, mas observe:

o squid e os servidores internos se comunicam falando http (e isso eh desejavel, pois os servidores internos nao falam https), ou seja o que esta acontecendo atualmente eh o seguinte:

1 - o cliente na intert faz um pedido http.
2 - eu coloquei o redirect pra https, ou seja o pedido http e redirecionado pra um pedido https.
3 - o cliente e o squid falam https agora (a tela de login da aplicacao aparece em https, e.g. https://pagina).
4 - o squid repassa o pedido pro servidor que estah por tras, em http, por que estes servidores nao falam https, e isto eh o comportamento que eu quero que ele tenha para com os servidores internos.
5 - o servidor responde pro squid em http, o que tambem eh desejavel.
6 - o squid responde em http pro cliente na internet.

Eh justamente o que acontece no passo 6 que eh o que eu NAO quero. O ideal eh que ele responda em https pra conexoes fora da rede 10.0.0.0, que eh a minha rede interna.

Estou pensando em usar o apache com mod_proxy.

Mas eh um saco setar o apache com ssl no Mac OS X. Por isso soh quero usar essa solucao se nao tiver jeito mesmo.

[gmlinux]

Qual é a versão do squid?
Sua aplicação gera telas ou sua página possui links que indicam o protocolo http? vc precisa continuar passando para o cliente links com https://

[webmail:/usr/local/squid] root# sbin/squid -v
Squid Cache: Version 2.5.STABLE6
configure options: --enable-ssl

o script que faz o redirecionamento da pagina eh algo como:

#!/usr/bin/perl -p
BEGIN { $| = 1; }
s%^http://servidor.externo.1%http://ip.servidor.interno.1% && next;
s%^http://servidor.externo.2%http://ip.servidor.interno.2% && next;
s%^http://servidor.externo.3%http://ip.servidor.interno.3% && next;

e assim por diante.

Funciona da seguinte forma:

O cliente da internet digita http://servidor.externo.1, o squid intercepta o pedido e repassa para o servidor interno.

A aplicacao tem varios links.

vc precisa continuar passando para o cliente links com https://

Eh justamente isso que eu queria que o squid fizesse, mas quando o servidor interno me responde em http (o que eh desejavel) o squid responde ao cliente na internet em http tambem e nao em https que eh o que deve ser.

Valeu!

[gmlinux]

[webmail:/usr/local/squid] root# sbin/squid -v
Squid Cache: Version 2.5.STABLE6
configure options: --enable-ssl

o script que faz o redirecionamento da pagina eh algo como:

#!/usr/bin/perl -p
BEGIN { $| = 1; }
s%^http://servidor.externo.1%http://ip.servidor.interno.1% && next;
s%^http://servidor.externo.2%http://ip.servidor.interno.2% && next;
s%^http://servidor.externo.3%http://ip.servidor.interno.3% && next;

e assim por diante.

Funciona da seguinte forma:

O cliente da internet digita http://servidor.externo.1, o squid intercepta o pedido e repassa para o servidor interno.

A aplicacao tem varios links.

vc precisa continuar passando para o cliente links com https://

Eh justamente isso que eu queria que o squid fizesse, mas quando o servidor interno me responde em http (o que eh desejavel) o squid responde ao cliente na internet em http tambem e nao em https que eh o que deve ser.

Valeu!

Quando o cliente clica em um link do seu servidor, se ele indicar http, o browser do cliente faz uma requisição http no squid, por iso vc deve indicar https.
Eu acho mais fácil configurar o server para https...

Vou tentar ser mais especifico:

Eu tenho um classe C de IP´s validos, ou seja 254 enderecos.

Eu tambem tenho 60 servidores de uma determinada aplicacao (sem contar os outros servidores criticos que tambem exitem).

Eh um para cada regional de nossa empresa.

Como nos temos mais servidores do que IP´s disponiveis resolvemos fazer o seguinte:

Colocar uma maquina pra responder por cada um desses 60 servidores, ou seja, a gente deu um unico ip valido pra essa maquina (a maquina do sqiud com http accelerator) e colocamos no dns varios nomes que apontam pro mesmo ip/maquina.

por exemplo quando um cara em Sp, da internet, digita:

http://servidor.aplicacao.sp

O mesmo procedimento com o cara do Rio, de Salvador, de POA etc.

Cada regional tem seu respectivo servidor.

Essa maquina (a com o squid) intercepta o pedido e invoca o servidor adequado, estes 60 servidores esta na minha rede interna.

O squid esta atras de um firewall, mas nao ha nenhuma restricao quanto aos servicos http e https.

Eh importante salientar que a interceptacao da comunicacao entre as maquinas se dah nos dois sentidos, ou seja, o cliente faz um pedido da internet, o squid intercepta e manda pro servidor adequado. O servidor responde pro squid, que responde pro cliente que fez a solicitacao.

Ou seja pro cliente o squid nao existe, mas o servidor que esta por tras soh fala com o squid.

O problema com o https eh que essa aplicacao (a dos 60 servidores que estao por tras) usa um outro formato de certificado digital (PKCS - binario) enquanto o squid usa o formato PEM (texto plano), de forma que pra que o servidor falasse com squid em https eles teriam que ter necessariamente o mesmo certificado no mesmo formato (na verdade poderiam ateh ter certificados diferentes, pois eh o squid quem responde pra fora, mas essas PKCS custam $$$$).

Nao sei voces, mas eu nao aceito o fato de ter que comprar 60 certificados pros servidores que estao por tras. Isso eh inadimissivel.

Por isso adotamos (ou estamos tentando) adotar essa solucao.

Bom acho que isso eh tudo.

De repente ateh exista uma outra solucao sem necessidade do squid. Como jah mencionei anteriormente, conheco a solucao com o apache+mod_proxy, mas alem de ser uma dor de cabeca pra fazer isso no darwin (compilar e instalar o squid com ssl - pra que vcs tenham ideia o sistema nem mesmo vem com compilador na instalacao default, mesmo apesar de se auto entitular Mac OS X 'Server'), temo que recaia no mesmo problema que acontece com o squid.

Ou seja o problema principal eh que o squid esta respondendo na mesma porta que ele recebe a resposta do servidor interno (80) mesmo que a conexao inicial do cliente seja em https.

De fato, se o cliente digitar https://servidor, ele ira conectar-se ao nosso servidor via https, porem as transacoes posteriores nao serao em https, mas em http.


Obrigado a todos pela ajuda e desculpem o incomodo e a burrice !

[ytzhak]

Oi eu sou o Visitante aih.

Achei melhor me cadastrar pq esse nao eh um nome muito comum.

[gmlinux]

...
Colocar uma maquina pra responder por cada um desses 60 servidores, ou seja, a gente deu um unico ip valido pra essa maquina (a maquina do sqiud com http accelerator) e colocamos no dns varios nomes que apontam pro mesmo ip/maquina.
...
Eh importante salientar que a interceptacao da comunicacao entre as maquinas se dah nos dois sentidos, ou seja, o cliente faz um pedido da internet, o squid intercepta e manda pro servidor adequado. O servidor responde pro squid, que responde pro cliente que fez a solicitacao.
...
Ou seja o problema principal eh que o squid esta respondendo na mesma porta que ele recebe a resposta do servidor interno (80) mesmo que a conexao inicial do cliente seja em https.

Saquei..., seguinte, eu usei esta configuração aqui

https_port 443 cert=/etc/squid/key.crt key=/etc/squid/key.key
httpd_accel_host 10.x.x.x
httpd_accel_port 80
httpd_accel_single_host off
httpd_accel_with_proxy on
httpd_accel_uses_host_header off

criei as chaves assim
openssl req -x509 -newkey rsa:2048 -keyout key.key -out key.crt -days 365 -nodes

abri o "server" squid com https e este abrindo um server http 10.x.x.x, meu browser recebeu o certificado normal e abriu a página, aparentemente, funcionou, no browser ficou a identificação de criptografado (cadeado), do lado do server, infelizmente não tinha um sniffer para verificar, logo não posso afirmar com certeza que funciona.

[ytzhak]

Na verdade eu jah fiz isso. Os certificados jah estao criados e funcionando, pelo menos na primeira conexao.

Como disse, quando o clinte acessa a pagina inicial da aplicacao, a pagina eh acessada via https. Mas pra links internos a comunicacao eh redirecionada via http.

Ex: O endereco do servidor de SP eh http://servidor.sp. Nessa primeira pagina ha um pedido de login e senha.

Se o cara digitar https://servidor.sp, ele consegue acessar a pagina via https, mas quando ele entra com os dados no campo login e senha e entao clica em logar, ele eh redirecionado pra uma conexao http.


Agora, eu nao encontrei ainda a razao pela qual a primeira pagina eh respondida em https e as posteriores nao.

Depois que o cara passa pra pagina seguinte, suponhamos, http://pagina.depois.do.login.e.senha e tentar digitar manualmente no browser https://pagina.depois.do.login.e.senha aih entao todas os outros pedidos sao efetuados via https. Por isso estava tentando fazer com ipfw e nat, pra tentar forcar todas as conexoes pedidas pra porta 80 serem redireciondas pra porta 443.


A proposito, tambem faco matematica.

8)

[gmlinux]

Quando o cliente loga, é como eu disse acima, sua aplicação esta redirecionando o browser para um link com http:// no inicio, isto orienta o browser a uma nova requisição, só que em http, eu fiz o teste ontem, se o site remoto fizer uma referência a ele mesmo, através de links relativos, conexão permanece https, se ele fizer com link absoluto usando a indicação de protocolo (http://) no início, ai o squid não pode fazer mais nada...

Se fosse vc, faria um teste usando até um site remoto (eu usei o underlinux), meu browser deu uma reclamada pois o under enviava alguns dados que não eram criptografados (aqueles contadores de page viewers), no mais, a conexão permaneceu em https, conforme o browser havia requisitado inicialmente.

Vc pode criar uma página básica tambem, só para teste.

Eu fiz uma pesquisa na net, e em muitas listas isto é confirmado.