Por que proxy não transparente é melhor que o transparente
Autor: Leonardo S Santos | Publicado: 2011-06-29T11:14:00-03:00

A explicação simples é a de que, além de ser  mais seguro, o proxy não transparente usa o recurso do cache de DNS.  Para a explicação detalhada, leia o post:

Como funciona o proxy?

A palavra proxy significa literalmente procurador. No caso de um  proxy HTTP, o servidor recebe uma requisição HTTP, a interpreta e  executa as ações necessárias para respondê-la. Como geralmente possui um  cache, ou ele responde com o conteúdo do cache, ou requisita o recurso  (arquivo) ao servidor HTTP original, desta vez como um pedido próprio.

Proxy Transparente

O proxy transparente é uma arquitetura que permite que o navegador  cliente não saiba da existência do proxy. Ele acha que está solicitando o  recurso diretamente ao servidor original; o proxy encarrega-se de  capturar e processar a solicitação.
A principal vantagem nesta arquitetura é que não é necessária a  configuração de proxy nos navegadores cliente. Outra (incorretamente)  alegada vantagem é que o proxy não transparente não impede a conexão  direta à Internet.
Como fica o navegador?
Uma requisição comum de um agente HTTP se dá em duas fases:
1) há a requisição DNS para resolver o endereço de destino;
2) é feita a requisição HTTP propriamente dita.
Se o navegador não conhece a existência do proxy, ele irá fazer  inicialmente a requisição DNS e, após resolvido o endereço, irá lançar a  requisição HTTP ao servidor original. O proxy, por sua vez, não irá  usar o DNS resolvido pelo navegador, e fará sua própria requisição DNS  antes da requisição HTTP.
Existe uma consideração importante: apesar de o pacote DNS ser  pequeno e transmitido em UDP, o tempo de resolução costuma não ser  desprezível. Às vezes, chega a mais de um minuto. E é o minuto mais  importante, porque fica entre o  e o aparecer alguma coisa  no navegador.
É, portanto, interessante para a LAN ter um cache DNS interno  servindo a todas as máquinas. Isto pode ser feito com a instalação de um  servidor DNS ou com o uso do cache DNS do próprio Squid.
Se o navegador conhece o servidor proxy, ele não fará nenhuma  resolução DNS e fará a solicitação do recurso ao servidor proxy, não ao  servidor original.

DNS com Squid e BIND

O Squid possui um cache DNS interno que pode ser acessado com o CGI  Cache Manager (no debian, pacote squid-cgi ou squid3-cgi), item Internal  DNS Statistics. O recurso é tão bom que diz o quanto tempo falta para  cada entrada DNS expirar.
Não achei recurso semelhante no BIND (servidor DNS mais usado no  mundo). No máximo, estatísticas gerais. O BIND é dividido em duas  partes: servidor com autoridade e servidor de encaminhamento. Segundo  sua documentação, é focado na performance.
Quando fiz meu TCC, tive que analisar algumas centenas de requisições  DNS. E apesar de não ter visto os dados concretos do BIND, tive a  nítida impressão de que o Squid é mais confiável no quesito cache. Ele  visivelmente fazia menos encaminhamentos (ou seja, dava mais respostas  de cache).
Segurança
Os vírus não usam proxy. Eles assumem uma conexão direta a Internet.  Quando se usa proxy transparente, você está encaminhando as mensagens de  vírus para a Internet. Simples assim.
Uma segunda consideração está relacionada também à conectividade: no  modelo não transparente, os navegadores não precisam estar conectados à  Internet. Eles só precisam estar conectados ao proxy e este se vira pra  chegar à web. Se você costuma usar apenas web, então pode usar um  gateway falso nos clientes. Isso significa que os softwares que não  conhecerem o proxy não poderão iniciar mensagens para a Internet, pois  não sabem a rota. Às vezes, pode ser útil.
Além disso, não é válido o argumento de que não se pode controlar a  conexão no proxy não transparente. No proxy transparente, captura-se o  pacote e, dessa forma, assegura-se que ele irá seguir o caminho do  proxy. Na arquitetura de proxy não transparente, pode-se inibir o uso de  Internet sem o proxy colocando-se um filtro do netfilter (via iptables)  no firewall.
Se o proxy está no gateway, deve-se permitir (ACCEPT) pacotes para a  porta 80 (--dport) apenas vindos da própria máquina (OUTPUT) e deve-se  bloquear (DROP) as vindas da rede (FORWARD) para fora.
Se o proxy não está no gateway, deve-se permitir pacotes na porta 80 cuja fonte (-s) seja o proxy e bloquear as outras.
A sintaxe é aproximadamente essa:
proxy na mesma máquina firewall/gateway.
# iptables -A INPUT --dport 80 -j ACCEPT //requisições da LAN para o proxy
# iptables -A FORWARD --dport 80 -j DROP //requisições da rede pra fora
# iptables -A OUTPUT --dport 80 -j ACCEPT //requisições do proxy pra fora
proxy em máquina interna da rede.
# iptables -A FORWARD -s  --dport 80 -j ACCEPT //requisições do proxy pra fora
# iptables -A FORWARD --dport 80 -j DROP //requisições da rede pra fora

Conclusão

Quanto à performance, existem duas formas eficientes de se fazer a  dobradinha proxy/cache e cache DNS. Usando proxy transparente e servidor  DNS ou usando o Squid como proxy não transparente.
Na primeira forma, deve-se colocar o servidor DNS interno à LAN e  fazer com que tanto o proxy quanto a LAN utilizem-no. É comum as LAN  Houses e mesmo as pequenas empresas usarem o servidor DNS do provedor.  Isso é prejudicial no proxy transparente, já que as requisições são  individuais dos navegadores, gerando tráfego desnecessário.
Na segunda forma, o servidor proxy Squid encarrega-se de fazer o  próprio cache DNS. Esta implementação é mais simples e mais econômica em  recursos. Pela "filosofia" KISS, pode-se dizer que é melhor.
E se houver um duplo uso de cache? Proxy não transparente + servidor  DNS interno? Fiz isso no meu TCC, pensando que era a melhor saída. Pelo  que pude analisar (com squid 2.7 e BIND 9.5), sempre que o squid  requisitava DNS, o BIND9 encaminhava a requisição. Ou seja, o squid era  suficiente. Além do mais, o servidor BIND estava configurado para  realizar requisições em múltiplos servidores DNS caso o simples  encaminhamento falhasse. O tráfego era enorme e redundante.
Quanto à segurança, parece-me que o melhor mesmo é usar proxy não  transparente, principalmente por causa dos vírus, trojans e toda a fauna  de processos mal intencionados no sistema operacional. No Windows, isso  é vital. Coloca-se um gateway e servidores DNS falsos e processa-se  apenas o que vier através do navegador. Sugiro utilizar uma máquina  válida preparada para receber os pacotes não autorizados, de modo que  identifique-se, via tcpdump, a origem e intenção destes pacotes.
Uma preocupação constante é quanto à facilidade de configuração da  rede. Para isto, há o método do proxy auto-config (PAC). Sobre ele, você  pode ler mais aqui e aqui.
Pelos motivos explanados acima, é possível considerar que em  ambientes simplificados o uso de proxies não transparentes ofereça mais  vantagens que desvantagens em relação aos transparentes. Claro que cada  caso é um caso. Às vezes, a vantagem na facilidade de implantação do  proxy transparente pode suplantar todas as vantagens do outro modelo.


fonte: lucianopinheiro