Configuração automática de proxy nos clientes

Usar um proxy transparente é a forma mais simples de fazer com que todas as estações da rede utilizem o proxy, sem precisar configurar cada uma das máquinas manualmente. Entretanto, usar um proxy transparente está longe de ser uma solução perfeita, pois o proxy só atende a requisições na porta 80 (ou seja, não funciona para FTP, HTTPS e outros protocolos) e usar o proxy transparente automaticamente impede que seja usada autenticação dos usuários.

Se você acha as limitações de usar um proxy transparente pesadas demais, mas também não quer arcar com o trabalho de configurar cada estação para usar o proxy manualmente, existe a opção de usar um script PAC (Proxy Auto-Configuration), um arquivo que é disponibilizado na rede local através de um servidor web.

Os clientes são então configurados para buscarem a configuração de proxy no script. Esta não é exatamente uma configuração automática (você ainda tem o trabalho de configurar os clientes para utilizarem o script), mas é um bom ponto de partida. A principal vantagem em relação à configuração manual é que ao usar o script você pode alterar a configuração de proxy em todas as estações simplesmente modificando o script, em vez de precisar reconfigurar cada estação manualmente.

Para começar, você precisa instalar um servidor web em algum servidor da rede, que será usado para disponibilizar o arquivo. Para manter as coisas simples, você pode utilizar o próprio servidor que está disponibilizando o proxy. Basta instalar o Apache usando o gerenciador de pacotes, como em:

# apt-get install apache2

ou:

# yum install httpd

Em seguida, crie o arquivo “/var/www/wpad.dat” (no servidor), com o seguinte conteúdo:

function FindProxyForURL(url, host)
{
return “PROXY 192.168.1.1:3128“;
}

No exemplo, o “192.168.1.1:3128” corresponde ao endereço do servidor proxy e a porta utilizada pelo Squid.

O diretório “/var/www” é o diretório raiz do servidor web, de forma que ao colocar o arquivo wpad.dat dentro dele, ele passará a ser disponibilizado através do endereço “http://ip-do-servidor/wpad.dat”, como em “http://192.168.1.1/wpad.dat”. O arquivo contém um pequeno javascript que será processado pelos clientes antes de cada requisição orientando-os a utilizarem o proxy.

O arquivo wpad.dat pode incluir diversos outros parâmetros. Aqui temos uma versão um pouco mais incrementada do arquivo, que inclui exceções para o site da empresa (ou outro site qualquer, que você defina) e para a faixa de endereços da rede local; endereços que devem ser acessados diretamente, sem passar pelo proxy:

function FindProxyForURL(url, host) {
if (shExpMatch(url,”*.gdhpress.com.br/*”)) {return “DIRECT”;}
if (isInNet(host, “192.168.1.0”, “255.255.0.0”)) {return “DIRECT”;}
return “PROXY 192.168.1.101:3128”;
}

Você pode ver uma lista com outros parâmetros que podem ser usados no:
http://wp.netscape.com/eng/mozilla/2.0/relnotes/demo/proxy-live.html

Depois de disponibilizar o arquivo, falta apenas configurar os clientes para obterem a configuração de proxy através dele. No Firefox, o endereço vai no “Editar > Preferências > Avançado > Rede > Configurações > Endereço para configuração automática de proxy”, enquanto no IE vai no “Ferramentas > Opções da Internet > Conexões > Configurações da LAN > Usar script de configuração automática”:

Depois de feita a configuração, você pode checar o uso do proxy pelos clientes monitorando o arquivo “/var/log/squid/access.log” do servidor. Você verá várias entradas referentes aos acessos feitos pelos clientes.

Essa é a configuração mais elementar, onde os clientes são manualmente configurados para utilizarem o arquivo. O degrau seguinte é o WPAD (Web Proxy Auto-Discovery protocol), que permite automatizar a configuração dos clientes, permitindo que eles localizem o arquivo automaticamente.

Para usar o WPAD, precisaremos configurar também o servidor DHCP e o servidor DNS da rede para orientarem os clientes a utilizarem o arquivo. A alteração do servidor DHCP consiste em adicionar duas linhas no arquivo “/etc/dhcp3/dhcpd.conf“, a primeira contendo a diretiva “code 252 = text” e a segunda contendo a localização do arquivo wpad.dat:

option wpad-url code 252 = text;
option wpad-url “http://192.168.1.1/wpad.dat\n”;

A primeira linha é incluída na seção global da configuração, enquanto a segunda é incluída na seção correspondente à subnet, como em:

ddns-update-style none;
default-lease-time 600;
max-lease-time 7200;
authoritative;
option wpad-url code 252 = text;

subnet 192.168.1.0 netmask 255.255.255.0 {
range 192.168.1.100 192.168.1.199;
option routers 192.168.1.1;
option domain-name-servers 208.67.222.222;
option broadcast-address 192.168.1.255;
option wpad-url “http://192.168.1.1/wpad.dat\n”;
}

O “/n” na última linha insere uma quebra de linha. Ele é um workaround para um bug do IE 6.0, que não lê a configuração se o \n não estiver presente. Depois de alterar o arquivo, não esqueça de reiniciar o serviço para que a alteração entre em vigor.

Depois de configurar o DHCP, você pode configurar os clientes com a opção “Detectar automaticamente as configurações” na configuração do proxy, em vez de especificar a localização do arquivo manualmente:

Atualmente, apenas o Internet Explorer é compatível com a configuração automática via proxy. Você pode selecionar a opção “Autodetectar as configurações de proxy para esta rede” no Firefox, mas você perceberá que os clientes continuarão tentando acessar a web diretamente, sem lerem o arquivo wpad.dat e sem utilizarem o proxy:

Isso nos leva à configuração do DNS, que complementa a configuração, atendendo a máquinas com o Firefox, Opera e outros navegadores.

A configuração do DNS é um pouco mais complexa, pois é necessário configurar também um domínio para a rede local e ajustar (novamente) também a configuração do servidor DHCP para que os clientes utilizem o domínio.

Mais adiante teremos um capítulo dedicado à configuração de servidores DNS utilizando o Bind, onde veremos mais detalhes sobre a configuração de domínios. Por enquanto, vou apenas me limitar a uma receita rápida para que você coloque o domínio no ar e possa assim ativar a configuração automática do proxy.

O primeiro passo é instalar o Bind usando o gerenciador de pacotes, como em:

# apt-get install bind

O arquivo de configuração padrão é o “/etc/bind/named.conf”. A configuração do domínio é feita em duas partes. Primeiro adicionamos uma entrada referente ao domínio no arquivo principal, indicando a localização de um arquivo externo (onde vai a configuração) e em seguida adicionamos a configuração propriamente dita neste segundo arquivo. Como estamos configurando um domínio local, você pode especificar qualquer domínio, não é necessário que ele esteja realmente registrado. No exemplo, estou usando o domínio “gdhn.com.br”.

Comece adicionando a configuração referente a ele no final do arquivo “/etc/bind/named.conf” (no Debian você pode também utilizar o arquivo “/etc/bind/named.conf.local”, que é carregado como um include):

zone “gdhn.com.br” IN {
type master;
file “/etc/bind/db.gdhn”;
};

Veja que na terceira linha especificamos o arquivo externo (db.gdhn), onde irá a configuração do domínio. Esse arquivo precisa ser criado na mesma pasta do arquivo principal, ou seja, será o arquivo “/etc/bind/db.gdhn“. O conteúdo do arquivo será o seguinte (veja mais detalhes sobre o significado das opções no capítulo sobre DNS):

@ IN SOA etch.gdhn.com.br. hostmaster.gdhn.com.br. (
2008030645 3H 15M 1W 1D )
NS etch.gdhn.com.br.
gdhn.com.br. A 192.168.1.1
wpad IN A 192.168.1.1

O “etch” no exemplo é o nome do servidor, enquanto o “192.168.1.1” é o endereço IP usado por ele. Isso cria o domínio “gdhn.com.br” e o “wpad.gdhn.com.br”, ambos apontando para o endereço IP do servidor. Dessa forma, ao tentarem baixar o arquivo “http://wpad.gdhn.com.br/wpad.dat”, os clientes baixarão na verdade o “http://192.168.1.1/wpad.dat”. Depois de terminar, não esqueça de reiniciar o Bind para que a alteração entre em vigor:

# /etc/init.d/bind restart

Naturalmente, para que o domínio seja utilizado, é necessário também configurar os clientes para utilizarem o servidor DNS interno que acabamos de configurar. Isso é feito especificando o endereço IP do servidor como único servidor DNS na opção “domain-name-servers” da configuração do DHCP e adicionando duas novas opções na seção global do arquivo:

ddns-domainname “gdhn.com.br.”;
option domain-name “gdhn.com.br.”;

Este é um exemplo de arquivo “/etc/dhcp3/dhcpd.conf“, depois das alterações:

ddns-update-style none;
default-lease-time 600;
max-lease-time 7200;
authoritative;
option wpad-url code 252 = text;
ddns-domainname “gdhn.com.br.”;
option domain-name “gdhn.com.br.”;

subnet 192.168.1.0 netmask 255.255.255.0 {
range 192.168.1.100 192.168.1.199;
option routers 192.168.1.1;
option domain-name-servers 192.168.1.1;
option broadcast-address 192.168.1.255;
option wpad-url “http://192.168.1.1/wpad.dat\n”;
}

Com essa configuração, os clientes Linux receberão a seguinte configuração de DNS (salva no arquivo “/etc/resolv.conf”) do servidor DHCP:

search gdhn.com.br.
nameserver 192.168.1.1

Veja que é incluída a linha “search gdhn.com.br”, que especifica que eles devem fazer pesquisas dentro do domínio e que o endereço do servidor é usado como DNS primário.

Naturalmente, a mesma configuração é fornecida aos clientes Windows configurados via DHCP. Veja um exemplo:

Com isso, você pode configurar o Firefox para localizar o proxy automaticamente e, graças à configuração do DNS, ele será capaz de encontrar o arquivo wpad.dat e utilizar a configuração definida por você.

Uma pequena exceção fica por conta de versões antigas do Firefox para Linux, que possuem um bug na variável usada para localizar o arquivo. Em vez de procurarem o arquivo wpad.dat no host “wpad” dentro do domínio da rede (que leva ao nosso servidor), elas tentam sempre baixar o arquivo a partir da URL “http://wpad/wpad.dat”, sem respeitar a configuração do DNS.

Ao usar clientes Linux rodando alguma das versões afetadas pelo bug, você verá uma série de entradas como essa no log do Squid:

192.168.1.183 TCP_MISS/503 1479 GET http://wpad/wpad.dat – DIRECT/wpad text/html

A solução nesses casos é editar o arquivo “/etc/hosts” nos clientes afetados, adicionando uma entrada relacionando o host “wpad” com o endereço do seu servidor, como em:

192.168.1.1 wpad

Com isso, as requisições passam a ser destinadas ao endereço correto, solucionando o problema.