Obter todo o tráfego HTTP com um proxy

Question

Gostaria de configurar um servidor proxy que receba todo o tráfego HTTP na minha rede. Eu penso em usar o Squid instalado no Debian.

Abaixo do diagrama da rede:

Eu não quero configurar um servidor proxy na minha LAN porque não consigo configurar um servidor de proy em cada computador.

Alguém pode me dizer qual é a melhor maneira de fazer isso?

    

Answer 1

Sua melhor aposta é configurar o squid no modo transparente, mas seu diagrama de rede mudaria. Como o servidor proxy iria NAT, isso também substituiria seu Cisco como um roteador. (e enquanto isso, por que não remover o seu roteador ISP para não dobrar NAT? como se algum dia você quiser criar alguma VPN, você não pode em NAT duplo)

Veja um tutorial lá; link

Há um pequeno detalhe do tutorial que mostra como ele fez isso;

Squid Installation

To set up a transparent proxy with Squid, we start by adding necessary iptables rules. These rules should help you get started, but please make sure that they do not conflict with any of the existing configuration.

iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT--to-port 3128

The first rule will cause all outbound packets from eth1 (WAN interface) to have the source IP address of eth1 (i.e., enable NAT). The second rule will redirect all incoming HTTP packets (destined to TCP 80) from eth0 (LAN interface) to Squid listening ort (TCP 3128), instead of forwarding it out to WAN interface right away.

    

Answer 2

Esteja ciente de que existem efeitos colaterais de interceptar conexões com http e, de fato, em nosso suporte técnico para nosso produto ( WinGate ) apesar de apoiarmos interceptar conexões, recomendamos não fazer isso.

1. Se você estiver usando autenticação no proxy, o cliente não sabe que está falando com um proxy. Se um proxy quiser autenticar um cliente interceptado, ele só poderá enviar uma resposta 401 (não um 407) e isso parecerá ao cliente como se o servidor final estivesse solicitando a autenticação. Para uma página com recursos de muitos servidores, você pode ter várias caixas de diálogo de login aparecendo.

2. O cache se comporta de maneira diferente. Existem diretivas de cache específicas de proxy que não funcionam quando você está interceptando a conexão com o proxy.

3. Algumas explorações. Em seu cenário proposto, onde você está desviando a conexão do ASA para o proxy, o destino é reescrito pelo ASA e a conexão é finalizada no proxy. O proxy então tem apenas o cabeçalho do host para usar como base para fazer uma conexão upstream. Isso requer uma pesquisa de DNS adicional pelo proxy, o que pode resultar em uma resposta diferente da que o cliente recebeu quando pesquisou o site. Além disso, em alguns casos, os clientes se conectam a um IP permitido usando um cabeçalho de host para um site proibido. O IP permitido passa pelo firewall, mas o proxy procura o cabeçalho do host e se conecta ao IP diferente (banido).

Você provavelmente também vai querer considerar o que fazer com os https.

Disclaimer: Eu trabalho para Qbik, que são os autores do WinGate.