por Jennifer Vesperman - 25/10/2001
O uso de proxy transparente libera você do trabalho de configurar os browsers individualmente para trabalhar com proxies. Se você tem uma centena, ou um milhar, de usuários em sua rede, é uma dor de cabeça configurar cada browser para usar proxies -- ou para convencer os usuários para editar as preferências do browser e escrever aqueles símbolos que eles não entendem.
Usando proxy transparenet, você intercepta as solicitações de páginas da web e redireciona as mesmas através do proxy. Bonito e simples -- por cima.
O uso de proxy transparente (também conhecido como sequestro de TCP -- "TCP hijacking") é parecido com o "Network Address Translation" (NAT) em alguns aspecots: deve ser evitado a todo custo, e somente usado se não há, absolutamente, positivamente, nenhum outro jeito.
Por que? Por que o proxy transparente não funciona bem com certos browsers web. Com a maioria dos browsers ele funciona bem, mas mesmo se um quarto de seus usuários está usando browsers mau-comportados, você pode esperar que os custos de help desk excedam qualquer benefício que você pode ganhar com o proxy transparente. Infelizmente, estes browsers são largamente utilizados.
Estes browsers se comportam de forma diferente se sabem que há um proxy -- todos os outros browsers seguem o padrão, e a única alteração que eles fazem com um proxy é direcionar as solicitações para uma máquina e porta diferentes. Browsers que não se comportam bem deixam alguns cabeçalhos HTTP fora das solicitação, e só acrescentam os mesmos se sabem que há um proxy. Sem aqueles cabeçalhos, comandos de usuários como "reload" não funcionam se houver um proxy entre o usuário e a origem.
O proxy transparente também introduz uma camada de complexidade, que pode complicar transações que de outra forma seriam simples. Por exmeplo, aplicações baseadas em web que pedem um servidor ativo não podem fazer o teste do servidor fazendo uma conexão -- eles será conectado ao proxy em vez do servidor.
Como funciona o proxy transparente?
Um firewall ou outro redirecionador captura as conexões TCP direcionadas a portas específicas em hosts remotos (normalmente a porta 80), e direciona as mesmas para o servidor proxy local. O servidor proxy usa os cabeçalhos HTTP para determinar para onde ele deve fazer a conexão, e faz a conexão.
Administradores de sistema são geralmente pedidos para fazerem proxy transparente de FTP e SSL, mas estes protocolos não podem passar por proxy transparente. O FTP é um protocolo mais complexo que o HTTP, e dá menos dicas sobre a origem da solicitação. O SSL é criptografado e não contém dados úteis sobre o destino. Tentativas de decodificar o SSL são exatamente o que o SSL é feito para evitar: decodificar o SSL para proxy transparente -- isto é indistinguível de um "verdadeiro" ataque man-in-the-middle.
Para executar um proxy transparente, precisamos de um servidor entre o
cliente e o destino. Este servidor deve ter as facilidades necessárias para
combinar e redirecionar o tráfego, como o netfilter e o
iptables. Qualquer sistema de firewall capaz de Network Address
Translation e redireção de tráfego pode ser usado.
Você precisará configurar uma regra para capturar o tráfego destinado à porta 80 em hosts externos, e redirecionar este tráfego para a porta de um servidor proxy na máquina que está fazendo a interceptação.
Pode-se ter proxies que não estão na máquina que faz a interceptação, mas estes são mais complicados. Primeiro, o endereço de origem da solicitação não está mais disponível ao proxy -- ele é perdido no processo de redireção. Você pode resolver este problema usando NAT (Network Address Translation) de destino, mas você terá que rotear o tráfego do proxy de volta para o servidor que faz a tradução. Se você tentar fazer o proxy passar a resposta HTTP de volta diretamente, o cliente ficará confuso e (corretamente) irá recusar comunicar com o proxy. O proxy não é a máquina que o cliente pensa estar falando com -- o cliente pensa que está fazendo a solicitação para o servidor de destino. O proxy precisa rotear de volta através do interceptador, de forma que os endereços possam ser convertidos novamente, e deixar o cliente acreditando que está falando diretamente com o servidor web.
O protocolo HTTP/1.1 tornou a vida mais fácil para os proxies transparentes, tornando obrigatório o cabeçalho de host. Este cabeçalho contém o nome da máquina (conforme informado na URL) e permite web hosting virtual baseado em nomes, permitindo que o servidor web use o cabeçalho do host para determinar com qual página deve responder.
Para os proxies transparentes, ele dá ao proxy o nome de host. Tendo
recebido uma conexão à porta 80 que foi interceptada, o servidor proxy precisa
entender que não está recebendo uma URI (Uniform Resource Identifier) absoluta
completamente qualificada, mas uma URI relativa. Normalmente, um servidor
proxy recebe http://host/path, mas se o cliente pensa que está
falando diretamente com o servidor, e não um proxy, ele só pede por
/path.
O servidor proxy usa o cabeçalho HOST para recuperar a URI
completamente qualificada, e então checa seu cache e faz o serviço de proxy
usual.
O Squid pode ser utilizado para proxy transparente por que ele também foi projetado para ser um proxy reverso (também conhecido como acelerador HTTP, ou "HTTP accelerator"), e pode ler estes cabeçalhos de solicitação abreviados. No modo acelerador, ele fica em frente ao servidor web verdadeiro e recebe solicitações como se fosse o servidor web, portanto foi projetado com a habilidade de reconstruir URIs relativas. Para usar o Squid como proxy transparente, nós habilitamos este comportamento de acelerador web.
Quando usar o Squid como acelerador HTTP, configure o nome de host e a
porta que você quer que o proxy acelere. Isto previne que o Squid seja usado
como um HTTP relay arbitrário. Quando estiver usando o Squid no modo
acelerador como um proxy transparente, configure o host name para
virtual e a porta para qualquer porta para a qual queremos fazer
proxy transparente.
Intercepte e/ou redirecione o tráfego para a porta escolhida. Ter o proxy
na mesma máquina que faz a interceptação é preferível. O código exemplo usa o
iptables como mecanismo de redireção, e a porta 8080 como a porta
http_port do proxy.
Para uma máquina diferente
iptables -t nat -A PREROUTING -i $INTERFACE -p tcp --dport 80 -j DNAT --to 10.0.3.1:8080
Para a mesma máquina
iptables -t nat -A PREROUTING -i $INTERFACE -p tcp --dport 80 -j REDIRECT --to-port 8080
No arquivo squid.conf, configure estas opções:
httpd_accel_host virtual
httpd_accel_port 80httpd_accel_with_proxy on
httpd_accel_uses_host_header on
Note que você não pdoe fazer proxy transparente de mais de uma porta por vez. Os cabeçalhos HTTP não contém informação de porta, de forma que o Squid não pdoe saber para que porta a solicitação foi feita uma vez que a solicitação tenha sido interceptada.
Artigos relacionados:
A razão mais comum para usar o proxy transparente é para reduzir o trabalho de configurar web browsers. Administradores de sistema precisam estar cientes dos problemas comuns dos proxies transparentes, e determinar se eles são apropriados em seus ambientes. Se o usuário final está usando browsers que sabe-se que se comportam bem com proxies transparentes, e a máquina designada para fazer o serviço de proxy pode tratar a demanda, um proxy transparente pode ser uma solução efetiva.
Nenhuma destas fala sobre proxies transparentes, mas são úteis de qualquer forma.
$SQUID-HOME/etc/squid.conf
Versão inglesa oreillynet.com Copyright © 2000 O'Reilly & Associates, Inc.
Tradução do original em http://www.oreillynet.com/pub/a/linux/2001/10/25/transparent_proxy.html