Depois de tomar bomba durante quase dois meses, finalmente consegui solucionar o problema de comunicação da Conectividade Social da Caixa junto com proxy Squid transparente. Logo, venho montar esse artigo para tentar ajudar aos que passam pelo mesmo problema.
Meu BOX nat/proxy vinha rodando meio que nos trancos e barrancos há algum tempo sob a distribuição Red Hat 9. Com uma conexão que atendia a cerca de 40 clientes dentro de uma instituição, não podia deixar de tentar reconstruí-lo, assim que possível. Tomei a iniciativa disso há alguns meses, fiz testes e, achando que estava tudo pronto, coloquei-o em produção.
Logo na primeira semana, recebi reclamações do RH sobre o serviço da Caixa chamado Conectividade Social. Logo, percebi que realmente este não fazia a comunicação adequada com o site. Assim, minha dor de cabeça começou.
Soluções disponíveis
Voei em busca de maiores informações sobre o problema aqui no VOL e em toda a Internet, mas, como todos sabemos, muitas coisas funcionam para uns, mas quando você precisa implementar para atender sua necessidade, alguma coisa de errado acontece e o problema persiste. Procurei scripts, documentações e nada de resolver.
O que constatei
Vários colegas me deram os seguintes detalhes:
A máquina virtual java para que o funcionamento ocorra perfeito não pode ser o da SUN e sim o da Microsoft;
Até agora, a Conectividade Social funciona apenas no Internet Explorer;
Apesar da comunicação ser feita através da porta 80 (http), esta não deve passar por proxy.
Reunindo essas informações, passei a montar a idéia e partir do zero para a solução.
[1] Comentário enviado por mondragon em 15/01/2007 - 08:44h
provavelmente o problema não era a questão do proxy, problema seria a nacessidade de mais alguma ou algumas portas pra comunicação, voce tentou simples dar o nat para o site?
só para teste ou curiosidade na regra de redirecionamento da porta 80 para 3128 retire "-d ! obsupgdp.caixa.gov.br"
acredito que somente o nat resolveria o problema, assim você terá esse tipo de conexão passando pelo squid também e gerando log.
[2] Comentário enviado por tiago_herrmann em 16/01/2007 - 17:18h
Olá
o tráfego não deve passar pelo proxy transparente porque é https, e não http.
O squid não suporta https em proxy transparente, provavelmente por limitações técnicas.
Grande parte do problema é culpa da Caixa, pois não se deve enviar tráfego https pela porta 80.
[4] Comentário enviado por marlichsi em 17/01/2007 - 15:23h
Isso mesmo, tiago_herrmann. Concordo em gênero, número e grau. O pior de tudo é você tentar suporte com a Caixa. Ninguém sabe nada, não tem técnico capacitado prá sanar dúvida, e os que supostamente intitulam-se técnicos mandam você reinstalar o Windows, pois em todos os clientes deles estão funcionando.
[5] Comentário enviado por *fernanda* em 24/01/2007 - 11:02h
Nossa, eu também tive estes problemas. Hoje Tenho maq. com 98/2000/XP acessando o Conectividade Social sem problemas.
Tenho uma coleção de endereços IP da Caixa(nada prático), esse é do Internet Banking, caso alguém precise: internetcaixa.caixa.gov.br
O Java da $Microsoft é o MSJVM - há tb uma ferramenta de diagnóstico no site.
Tenho maq. com 98/2000/XP acessando o Conectividade Social sem problemas.
[6] Comentário enviado por luandaa em 21/03/2007 - 19:24h
eu estou com um problema serissimo ,meu windows é o xp ,até uma semana atraz funcionava o programa da conectividade ,conexao segura ,mais meu pc quebrou e tive que trocar a placa mae, depois disso os tecnicos de suporte da caixa acha que o meu microsoft vm esta danificado ,moral da historia a pagina da sempre mensagem de erros e eles mandam eu desistalar e instalar novamente ,agora como se pelo meus normais nao desistala e eles dizem que nao podem da suporte ,e eu nao sei como fazer ,peço ajuda de voces. meu email é luandaatavares@hotmail.com
[7] Comentário enviado por marceloespindola em 02/07/2007 - 15:58h
Meus caros amigos! discordo do Comentário enviado por tiago_herrmann quando foi dito que
"Grande parte do problema é culpa da Caixa, pois não se deve enviar tráfego https pela porta 80".
Meu amigo https trabalha na porta tcp 443 e não na 80 e jamais trabalhará nesta porta e não vai ser a caixa que vai fazer isso, o proxy transparente só funciona para o protocolo http que trabalha na porta 80, até agora somente conheço o site da radio uol que não funciona com proxy algum, mas o site trabalha mesmo assim na porta 80, até mesmo com o proxy da microsoft (IZA-SERVER) não funciona, mas existe regras para não passar pelo, porém não sei se aplica ao questionamento aberto por este artigo.
No entanto para que todos os sites sejem acessados e endereços externos também que funcionam em outras portas que não seja a 80 é suficiente colocar a seguinte regra no iptables posteriormente a do proxy transparente:
[8] Comentário enviado por tiago_herrmann em 03/07/2007 - 17:57h
marceloespindola,
HTTPS é protocolo de camada de aplicação, nada mais do que uma conversa http em um socket tcp com ssl. Sendo assim, é possível enviar este tráfego em qualquer porta. 443 é apenas uma convenção. Não afirmei isto sem embasamento, basta monitorar o trafego gerado na porta 80 com tcpdump. É nitidamente ssl. E qualquer tráfego da camada de aplicação pode ser enviado por qualquer uma das 65535 portas tcp. Se fosse seguir a sua linha de raciocínio não existiria a diretiva Port no apache. Basta olhar o seu log do proxy e ver que ele acha que está chegando lixo na conexão, que na verdade nao é lixo, é a negociação ssl.
Eu lembro de ter olhado dentro do codigo java script que efetuava a conexão e ter achado algo como
var='https://200.xxx.xxx.xxx:80'
o que deixa evidente o solicitação de tráfego https explicitamente na porta 80.
A regra que você colocou só faz mascaramento simples de requisições, e nada tem a ver com o problema citado, além de ter typos: iptables não tem I maiúsculo, a linha do WAN não pode estar comentada e a chain é POSTROUTING, e não POSROUTING. Sugiro a você um estudo aprofundado em modelo TCP/IP, proxy transparente, protocolo HTTP e SSL.
[9] Comentário enviado por heroes em 03/12/2007 - 09:34h
Estou usando um Fedora7 e li varios artigos sobre iptables mas nenhum me ajudou... todos dão a mema dica, para liberar o ip da caixa pra não passar pelo proxy, com a regra:
iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -o eth1 -j MASQUERADE
#regra que obriga o uso de proxy
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to 192.168.0.1:3128
#------fim------#
Coloquei o java da microsoft... e tudo mais... o teste que estou fazendo eh o seguinte, intalei a primeira parte do conectividade, ai habilitei o proxy, quando ele abre ele nao continua a instalação pq tem que pegar aruivos no site da caixa, mas se desabilitar o proxy ele vai blz...
Não sei mais como resolver... se puder me ajudar
Desde já agradeço a atenção.
# Regras do Firewall:
iptables -A INPUT -p icmp --icmp-type echo-request -j DROP
echo 1 > /proc/sys/net/ipv4/conf/default/rp_filter
iptables -A INPUT -m state --state INVALID -j DROP
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -i eth1 -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -p tcp --syn -j DROP
# Bloquear UDP de 0 a 1023:
iptables -A INPUT -p udp --dport 0:1023 -j DROP
echo "Regras de Firewall e Compartilhamento Ativados"
[11] Comentário enviado por marlichsi em 05/12/2008 - 18:32h
Boa-noite, inguants.180.
Fico muito feliz por ter lhe ajudado. Essa é a idéia. Comunidade! Livre! Um ajuda o outro. Já peguei muitas dicas aqui também que me livraram de uma tremenda dor-de-cabeça.
Sobre colocar o IP em vez do NOME: sempre fazia meus scripts baseados no IP, até que comecei a enfrentar problemas de mudanças de números para determinados sites. Assim, meus scripts paravam de funcionar.
Especificando o nome, quando há uma mudança do número IP você só precisa recarregar a regra.
Achei mais fácil dessa forma. Mas, nada impede de que você utilize especificando o número IP. Funciona da mesma forma.