Problema chato com iptables, squid, cache parent e sites que pedem autenticação (ufa)
Gente,
Venho aqui pedir ajuda para um problema que estou tendo no meu trabalho, e com o chefe no pé, piora ainda mais. A questão é o seguinte: Temos na escola um proxy Squid, (mal) configurado por mim, e que funciona a contento, ligado a um link de (não riam) 128 Kbps. O roteador que está nesse link deu defeito, ficamos sem internet... E posteriormente foi adicionado um novo link, de 512 Kbps, ligado ao departamento de informática da fundação ao qual estamos vinculados.
O proxy deles também é um Squid, e não podemos "ver" a internet a não ser através do proxy deles. Todo o tráfego passa por eles, e o proxy requer autenticação. Temos alguns usuários lá, e como coloquei o squid deles como cache parent do nosso squid, setei o login e senha de um desses usuários também, para evitar transtornos.
Quase tudo funciona bem, nosso Squid resolve no Squid deles, e tudo funciona. Só que alguns sites estão dando problema. São todos os sites que requerem algum tipo de login para o acesso, como fórums e sites que fornecem algum retorno. Também temos problemas com sites que usam protocolo seguro (https). A todos eles, temos a seguinte resposta do Squid:
O seguinte erro foi encontrado:
* Falha na conexão
O sistema retornou:
(113) No route to host
E justamente um dos sites que não conseguimos acessar é o sistema de lançamento de notas. Portanto, estou com o coordenador do curso técnico nos meus calos, pedindo nervosamente o acesso, que eu não consigo liberar.
A parte técnica vem agora:
Os IPs são:
Minha rede: 10.0.0.0/16
Sub-rede por onde o tráfego sai: 10.10.10.128/28
Proxy deles: 10.0.0.31
1) Pelo IP dado, entende-se que ele é interno à rede, mas na verdade é externo. Isso gera confusão. O que fiz foi criar uma rota (na tabela de roteamentos) para enviar quaisquer pacotes para esse IP pela placa de rede certa, no caso, a externa:
route add -host 10.0.0.31 gw 10.10.10.129 dev eth0
Dessa forma, qualquer requisição vinda do servidor é repassada pela placa de rede certa. Antes que perguntem... Sim, já troquei o IP interno do servidor e da rede para um que não gere conflitos, mas o problema continuou.
2) No script de firewall, eu desativei tudo, apenas deixei o IP forward e a tabela NAT ligados:
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -s 10.0.0.0/16 -o eth0 -j MASQUERADE
Não tem mais nada ativo. Mais espartano do que isso, impossível.
3) O squid.conf é simples, e o que acho que vale a pena ser dito é:
http_port 3128 transparent
O squid é transparente, mas eu tenho o proxy setado em todas as máquinas (justamente por causa de sites que usam https).
icp_port 0
Desativei por que o cache parent não usa.
cache_peer 10.0.0.31 parent 3128 0 login=xxxx:xxxx
O "feijão-com-arroz" de sempre.
De qualquer forma, posso repassar uma cópia completa dele, caso haja necessidade.
Considerações:
- Não dá para mexer no proxy deles, mudar nada por lá.
- Se configurar da forma que eles disseram (desligando o meu proxy, colocando na sub-rede deles e setando o proxy, usuário e senha), funciona redondo. Essa é a principal justificativa de que o proxy deles está ok, e o nosso não.
- Não dá para desligar o meu proxy porque iremos receber outro link em breve, de 1024 Kbps. Esse link será para os laboratórios de informática e o link de 512 Kbps, para o setor administrativo da escola. Através do Squid, faço controle de acesso, gero relatórios de tráfego, entre (muitas) outras coisas.
O que já tentei:
- Trocar os IPs, para outra faixa. No caso, 172.16.x.x, coloquei um micro direto no servidor. Neca.
- Várias regras de iptables, sem sucesso.
- Algumas configurações no squid.
- Lida de um monte de tutoriais.
O que eu desconfio:
Penso que a requisição é feita, mas o pacote não volta. Ou, se volta, o sistema não sabe quem pediu. Já tentei usar o tcpdump para ver o tráfego, mas não é nada claro o que ele apresenta na tela.
Logo, preciso da ajuda de vocês. Por isso, o texto detalhado, e o pedido de SOCORRO! veemente. =)
Obrigado por qualquer ajuda!
Um abraço, Ricardo.
