Conectividade Social vs. proxy Squid transparente

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.

[ Hits: 48.231 ]

Por: Marlichsi, o Mxyzptlk em 14/01/2007


Problemas no cliente e servidor



O problema no cliente

Percebi de imediato que os dois micros que eu estava fazendo testes possuíam a máquina virtual java da SUN. Desinstalei-os e instalei o da Microsoft. Para minha surpresa, de tantos testes que havia feito nestes dois micros, alguma coisa havia danificado o Windows a ponto de não aceitar mais instalação da máquina virtual java da Microsoft.

Quando verificava a instalação no Adicionar/Remover programas, percebia que este não aparecia ali na lista, mas o da SUN, quando instalado, sim. Logo descobri que esses dois micros não me atenderiam para fazer os testes. Montei um novo micro, reinstalando o Windows e instalando a máquina virtual java da Microsoft. Consegui instalar a versão 5.0.3810. Daí, parti para o lado do servidor (nat/proxy).

O problema no servidor

Fiz a instalação do Linux utilizando Fedora Core 5 numa arquitetura de 32 bits.

O que parecia ser uma coisa complexa, ficou simples depois que foi resolvido. Como recebi dicas de que a Conectividade Social, apesar de trabalhar na porta 80 (http), não deveria passar por proxy, apliquei uma regra ao BOX para redirecionar toda a conexão de minha rede interna com destino à porta 80 (http) para a porta 3128 (squid), excluindo o endereço que faz comunicação com a Conectividade Social.

/sbin/iptables -t nat -A PREROUTING -i eth0 -p tcp -d ! obsupgdp.caixa.gov.br --dport 80 -j REDIRECT --to-port 3128

Onde eth0: placa de rede interna;

Em seguida, como tenho como regra default o bloqueio de toda a rede acessar a internet diretamente pelo forward (/sbin/iptables -I FORWARD -s 192.168.1.0/24 -d 0/0 -j DROP), tive que aplicar uma regra em seguida para permitir que as solicitações ao endereço da Conectividade Social sejam permitidos, já que na regra de direcionamento de porta para o proxy transparente esse endereço não vai ser direcionado.

/sbin/iptables -I FORWARD -s 192.168.1.0/24 -d obsupgdp.caixa.gov.br -j ACCEPT

E também com o direito de retornar.

/sbin/iptables -I FORWARD -s obsupgdp.caixa.gov.br -d 192.168.1.0/24 -j ACCEPT
Página anterior     Próxima página

Páginas do artigo
   1. O problema
   2. Problemas no cliente e servidor
   3. Resumindo e considerações finais
Outros artigos deste autor

PHP >= 5.1 x horário de verão brasileiro

Leitura recomendada

Warsaw no Fedora 28 funcionando - Internet Banking

Instalando e configurando um servidor DNS (Bind)

Configurando um servidor DNS rápido e fácil

Replicação e balanceamento de carga em servidores usando DNS

Palm na internet via Linux

  
Comentários
[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.

[3] Comentário enviado por mautech em 17/01/2007 - 00:16h

kra em qual windows vc fez funcionar a conetividade!??


Abraços

Maurício

[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.

Windows XP, mautech.

[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.

blz

[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:

#WAN=interface_rede_externa
Iptables –t nat –A POSROUTING –o $WAN –j MASQUERADE

OK pessoal? espero ter ajudado na compreensão e no aprimoramento do conhecimento dos senhores. vlw!

[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.

Tiago.

[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 PREROUTING -i ethX -p tcp -d ! 200.201.174.207 --dport 80 -j REDIRECT --to-port 3128

ethx eh a placa de rede interna... Mas não tem adiantado... só desabilitando o proxy funciona...


#------minhas regras-----#
iptables -F
iptables -F -t nat

touch /var/lock/subsys/local

modprobe iptable_nat
modprobe ip_conntrack_ftp
modprobe ip_nat_ftp

echo 1 > /proc/sys/net/ipv4/ip_forward

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.

[10] Comentário enviado por inguants.180 em 05/12/2008 - 18:08h

Marciano G. Bosi

Muito obrigado pela ajuda !!!!
my friend you saved my life and my hair......hihihi

Funfou tudo certinho, so uma dica......melhor colocar o ip da caixa inves do site. abaixo vai meu script para quem quiser tirar duvidas.

Debian 4.0/Proxy Squid Transparente e SquidGuard.
Com este script roda tdo blz.

#!/bin/bash

iniciar () {

# Compartilhar Conexão:
modprobe iptable_nat
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
echo "Compartilhamento Ativado"

# Proxy Transparente
#iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80 -j REDIRECT --to-port 3128
iptables -t nat -A PREROUTING -i eth1 -p tcp -d ! 200.201.174.207 --dport 80 -j REDIRECT --to-port 3128
iptables -I FORWARD -s 192.168.1.0/24 -d 200.201.174.207 -j ACCEPT
iptables -I FORWARD -s 200.201.174.207 -d 192.168.1.0/24 -j ACCEPT
echo "Proxy Transparente Ativado"

# 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"

}

parar () {
iptables -F
iptables -t nat -F
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
echo 0 > /proc/sys/net/ipv4/ip_forward
echo "Regras de Firewall e Compartilhamento Desativadas"
}

case "$1" in
"start") iniciar ;;
"stop") parar ;;
"restart") parar; iniciar ;;
*) echo "Use os Parâmetros start ou stop"
esac


Obrigado.

[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.

[]'s


Contribuir com comentário




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts