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
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
É, 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
# 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
