Pessoal,
Estou a dias procurando, tem como chegar uma requisão no SQUID, e eu conseguir desvia-lá para outro host e porta. Não que fazer isso pelo iptables.
Atenciosamente,
Leonardo
Versão Imprimível
Pessoal,
Estou a dias procurando, tem como chegar uma requisão no SQUID, e eu conseguir desvia-lá para outro host e porta. Não que fazer isso pelo iptables.
Atenciosamente,
Leonardo
se você especificar um pouco mais o que você que, talvez seja possível ajudá-lo.
leia: --> https://under-linux.org/forums/assun...niciantes.html
Minha situação é a seguinte, tenho um Firewall(roteador da rede) em uma maquina, o proxy e o msn-proxy em outra, utilizo acesso a internet por autenticação no proxy, ai que esta o problema como fazer para que as requisições de msn sejem desviadas para o meu msn-proxy, tens alguma regra no squid para esse desvio??/
Acho que você pode fazer isso no seu Firewall (dependendo da topologia) ou no iptables mesmo. Que eu saiba não tem como fazer isso no squid.
Agora, se você só quer que as conexões de MSN passem pelo MSN-proxy, porque você não configura o MSN pra usar um proxy??
Já tentei fazer isso mas não consegui, como posso proceder para ersolver isso??? Alguem tem um case parecido.
iptables -t nat -A PREROUTING -d "proxy" -p tcp -m tcp --dport "porta-proy" -j DNAT --to-destination "msn-proxy":"porta-msn-proxy"
tente isso
Obrigado, mas esse comanda ira desviar todo meu trafego do proxy para o msn-proxy ai não dá.
Já to perdendo cabelo com isso.
Se no parâmetro porta_proxy você colocar as portas usadas pelo msn ele não irá redirecionar "todo o tráfego".
MAs igaula ira desviar todo meu trafego do meu proxy para o msn-proxy.
Não cara, se no parâmetro porta_proxy você definir somente as portas tcp utilizadas pelo msn (se não me falha a memória é a 1863 e umas outras) ele so vai fazer DNAT dos pacotes do MSN. O tráfego Web (que roda na porta 80) não será afetado
Tchê,
Mas as portas do msn são 80, 443 e 1863.
Relamente, pesquisei com mais calma e vi que o live messenger passou a utilizar a porta 80. É isso ai, a empresa do tio Bill dando mais trabalho pra gente...
Acho que isso aqui talvez te ajude:
https://under-linux.org/forums/proxy...m-conhece.html
Até mais...
Usa o iptables para fazer redirecionamentos de portas...
Quando vir solicitações da sua rede interna p/ tal porta redireciona p/ a máquina tal...Entendeu?
Citação:
Postado originalmente por Magnun
Eles tentam fazer alguma coisa p/ melhor a conexão usando apenas uma porta e esquecem que existem corporações que proibem o uso do msn!
Aí lascam tudo!
e aí..Como bloquear esse live agora rodando na porta 80? Se existe programas como o conectividade social e outros programas que não tem como bloquear a porta 80, pois só funciona nela?
Quando redireciona a porta 80 p/ 8080 ou até mesmo a do squid 3128, vc faz algumas regras no iptables p/ deixar requisições da máquina x quando partir p/ o ip de determinado banco deixar passar na porta 80. Só que andei liberando isso e fazendo teste com o live da microsoft e consegue passar pelo iptables mesmo especificando para só liberar a porta 80 só para determinandos ip ( ips de bancos, etc..).
Agora o negocio começou a complicar!
Acho que vamos ter que mexer na versão do iptables!
nesse link que eu postei ai em cima, um cara explica um jeito de bloquear o live messenger. Dá uma olhada...
Ainda estou com problemas, minha situação é o seguinte, tenho meu firewall e roteador da minha rede, meu servidor proxy e msn-proxy e minhas estações, não estou conseguinte fazer o msn-proxy funcionar com essa topologia, só que é o seguinte, não posso mudar essa topologia, pois os serviços que estão rodando nesse entorno já estão criticos e complexos.
Preciso fazer o msn-proxy funcionar com a topologia atual, no meu ambiente de teste funciona blz, pois uso o proxy como roteador. Mas no abiente de produção vai ser conforme o atual.
https://under-linux.org/forums/attac...1&d=1213649584
Como estão as regras do firewall??
O problema provavelmente é devido ao redirecionamento com Nat...
Use o Layer7 para jogar o MSN para seu msn-proxy.
Coloquei o IP do Proxy/msn-proxy representado com IP 10.0.0.2, e assim estão minhas regras no Firewall e Proxy/msn-proxy.
Ex.:
Regra do Firewall
iptables -t nat -A PREROUTING -i eth0 -p tcp -s ! 10.0.0.2/255.255.255.255 --dport 1863 -j DNAT --to-destination 10.0.0.2:1863
Regra do Proxy/msn-proxy
iptables -t nat -I PREROUTING -p tcp --dport 1863 -j REDIRECT --to-port 1863
Cara, é 99,9% de certeza que o seu problema é o seguinte:
Quando seu gateway recebe os pacotes de MSN ele executa a seguinte regra: iptables -t nat -A PREROUTING -i eth0 -p tcp -s ! 10.0.0.2/255.255.255.255 --dport 1863 -j DNAT --to-destination 10.0.0.2:1863
Que altera o IP de destino dos pacotes para 10.0.0.2.
Vou explicar passo a passo:
vamos supor que a máquina esteja usando o MSN tenha o IP 10.0.0.30, que o gateway seja o 10.0.0.1 e o MSN-proxy o 10.0.0.2.
Quando o host gera o pacote ele contem os campos IP de origem e IP de destino que respectivamente são os IP: 10.0.0.30 e 10.0.0.1.
Quando o gateway recebe esse pacote ele altera o IP de destino, de 10.0.0.1 para 10.0.0.2 e roteia o pacote.
Quando o MSN-proxy recebe o pacote ele processa e tenta responder, ao tentar responder ele envia diretamente para o host 10.0.0.30, uma vez que ambos estão na mesma rede (10.0.0.0/24) ele não encaminha o pacote para o gateweay.
Quando o host recebe o pacote com IP de origem 10.0.0.2 e IP de destino 10.0.0.30 (ele mesmo), ele simplesmente descarta esse pacote, pois ele requisitou essa conexão com o IP 10.0.0.1 e não com o 10.0.0.2! Deu pra entender ne?! Se esse pacote voltasse pelo gateway esse DNAT seria desfeito, e o host aceitaria a conexão...
Agora vamos pra solução:
1. Criar um SNAT, porém para o MSN-proxy todas as conexões estarão sendo abertas pelo gateway, 10.0.0.1 devido ao SNAT.
2. Mover esse MSN-proxy para outra rede (o que você disse que era inviável).
Qualquer dúvida posta ai...
Foi justamente o que detectei, ficou um trinâgulo, mas o problema é que tenho que fazer funcionar com essa topologia. Já quebrei a cabeça e ainda não achei solição para isso.
Como eu disse, para não alterar a topologia, você pode utilizar o DNAT e o SNAT porém, para o MSN-proxy "somente o gateway estará se conectando a ele". Se isso não impactar em nada no seu MSN-Proxy, então é a sua solução.Citação:
Postado originalmente por leonardoss
Vou fazer os testes agora pela manhã, após isso informo-lhes.
Puts,
Pior que não esta funcionando :
1ª Tentativa
Firewall
iptables -t nat -A POSTROUTING -p tcp -s ! 10.0.0.2 --dport 1863 -j SNAT --to 10.0.0.2
Msn-proxy
iptables -t nat -I PREROUTING -p tcp --dport 1863 -j REDIRECT --to-port 1863
2ª Tentativa
Firewall
iptables -t nat -A POSTROUTING -p tcp -s ! 10.0.0.2 --dport 1863 -j SNAT --to 10.0.0.2
iptables -t nat -A PREROUTING -i eth0 -s ! 10.0.0.2 -p TCP --dport 1863 -j DNAT --to 10.0.0.2
Msn-proxy
iptables -t nat -I PREROUTING -p tcp --dport 1863 -j REDIRECT --to-port 1863
Cara, acho que teria que ser:Citação:
Postado originalmente por leonardoss
iptables -t nat -A PREROUTING -i eth0 -s !MSN-Proxy -p TCP --dport portas -j DNAT --to MSN-Proxy
iptables -t nat -A POSTROUTING -s !MSN-Proxy -p TCP --dport portas --to GW
Dessa forma o destino será o MSN proxy e a origem o GW. A sua regra de prerouting DNAT tava ok, mas a de postrouting SNAT tava fazendo o pacote ficar com o os campos origem e destino iguais. As portas necessárias são somente essa 1863??
Blz, funcionou.
Firewall 10.0.0.1
iptables -t nat -A POSTROUTING -s ! 10.0.0.2 -p TCP --dport 1863 -j SNAT --to 10.0.0.1
iptables -t nat -A PREROUTING -i eth0 -s ! 10.0.0.2 -p TCP --dport 1863 -j DNAT --to 10.0.0.2
Msn-proxy 10.0.0.2
iptables -t nat -I PREROUTING -p tcp --dport 1863 -j REDIRECT --to-port 1863
Agora sim ta do jeito que eu quero, a unica coisa ruim que ficou nessa solução foi que o ip dos clients do msn-proxy ficam com o ip do firewall, mas já ta de bom tamanho pra mim.
Citação:
Postado originalmente por leonardoss
Ae!!! Que bom! Realmente o problema desse esquema é isso. A melhor forma mesmo é ter esse MSN-proxy em uma rede diferente da local... Mas esse proxy, não gera log com base nos usuários não??
Gera, mas era a nivel de ver de onde o usuário esta se conectando, mas isso seria uma perfumaria, não vamos perder tempo com isso.
Grato pelas ajudas, foram de grande importancia.