-Servidores Proxy (Squid) - Criando uma configuração básica
Autor: Gilberto | Publicado: 2008-07-14T10:28:00-07:00

O problema com o modelo de configuração minimalista que acabamos de ver é que com apenas estas quatro linhas o proxy ficará muito aberto. Se você deixar o servidor proxy ativo no próprio servidor que compartilha a conexão e não houver nenhum firewall ativo, qualquer um na internet poderia usar o seu proxy, o que naturalmente não é desejado. O proxy deve ficar ativo apenas para a rede local.   Vamos gerar, então, um arquivo mais completo, permitindo que apenas os micros da rede local possam usar o proxy e definindo mais algumas políticas de segurança. Neste segundo exemplo já aproveitei algumas linhas do arquivo original, criando regras que permitem o acesso a apenas algumas portas específicas e não mais a qualquer coisa, como na configuração anterior:  http_port 3128visible_hostname gdh  acl all src 0.0.0.0/0.0.0.0acl manager proto cache_objectacl localhost src 127.0.0.1/255.255.255.255acl SSL_ports port 443 563acl Safe_ports port 80 # httpacl Safe_ports port 21 # ftpacl Safe_ports port 443 563 # https, snewsacl Safe_ports port 70 # gopheracl Safe_ports port 210 # waisacl Safe_ports port 280 # http-mgmtacl Safe_ports port 488 # gss-httpacl Safe_ports port 591 # filemakeracl Safe_ports port 777 # multiling httpacl Safe_ports port 901 # swatacl Safe_ports port 1025-65535 # portas altasacl purge method PURGEacl CONNECT method CONNECT  http_access allow manager localhosthttp_access deny managerhttp_access allow purge localhosthttp_access deny purgehttp_access deny !Safe_portshttp_access deny CONNECT !SSL_ports  acl redelocal src 192.168.1.0/24http_access allow localhosthttp_access allow redelocal  http_access deny all  As acl's "SSL_ports" e a "Safe_ports" são as responsáveis por limitar as portas que podem ser usadas através do proxy. Neste exemplo, usei a configuração-modelo indicada na documentação do Squid, que prevê o uso de diversos protocolos conhecidos e também o uso de portas altas, acima da 1024. Ela é tão extensa porque cada porta é especificada em uma linha diferente. Podemos simplificar isso agrupando as portas na mesma linha, o que resulta em um arquivo de configuração muito menor, mas que faz exatamente a mesma coisa:  http_port 3128visible_hostname gdh  acl all src 0.0.0.0/0.0.0.0acl manager proto cache_objectacl localhost src 127.0.0.1/255.255.255.255acl SSL_ports port 443 563acl Safe_ports port 21 80 443 563 70 210 280 488 59 777 901 1025-65535acl purge method PURGEacl CONNECT method CONNECT  http_access allow manager localhosthttp_access deny managerhttp_access allow purge localhosthttp_access deny purgehttp_access deny !Safe_portshttp_access deny CONNECT !SSL_ports  acl redelocal src 192.168.1.0/24http_access allow localhosthttp_access allow redelocal  http_access deny all  Veja que em ambos os exemplos adicionei duas novas acl's. A acl "localhost" contém o endereço 127.0.0.1, que você utiliza ao usar o proxy localmente (ao navegar usando o próprio servidor), e a acl "rede local", que inclui os demais micros da rede local. Substitua o "192.168.1.0/24" pela faixa de endereços IP e a máscara de sub-rede usada na sua rede local (o 24 equivale à mascara 255.255.255.0).   Depois de criadas as duas políticas de acesso, vão duas linhas no final do arquivo que especificam que os micros que se enquadrarem nelas poderão usar o proxy:   http_access allow localhosthttp_access allow redelocal  Lembra-se da acl "all", que contém todo mundo? Vamos usá-la para especificar que os clientes que não se enquadrarem nas duas regras acima (ou seja, clientes não-autorizados, vindos da Internet) não poderão usar o proxy:   http_access deny all  Esta linha deve ir no final do arquivo, depois das outras duas. A ordem é importante, pois o Squid interpreta as regras na ordem em que são colocadas no arquivo. Se você permite que o micro X acesse o proxy, ele acessa, mesmo que uma regra mais abaixo diga que não.  Se você adicionasse algo como:  acl redelocal src 192.168.1.0/24http_access allow redelocalhttp_access deny redelocal  ... os micros da rede local continuariam acessando, pois a regra que permite vem antes da que proíbe.   Existem alguns casos de sites que não funcionam bem quando acessados através de proxies, um exemplo comum é o "Conectividade Social", da Caixa. Normalmente nesses casos o problema está em algum recurso fora do padrão usado pelo sistema do site e não no servidor proxy propriamente dito, mas, de qualquer forma, você pode solucionar o problema de forma muito simples orientando o servidor proxy a repassar as requisições destinadas ao site diretamente.   Para isso, adicionamos uma ACL na configuração, especificando a URL do site e usando a opção "always_direct":  acl site dstdomain siteproblematico.comalways_direct allow site  Esta regra deve vir antes da regra que libera os acessos provenientes da rede local, como em:  acl site dstdomain siteproblematico.comalways_direct allow site  acl redelocal src 192.168.1.0/24http_access allow localhosthttp_access allow redelocalhttp_access deny all  Depois de configurar o arquivo, não se esqueça de reiniciar o serviço para que a configuração entre em vigor:  # /etc/init.d/squid restart  Nesse ponto o seu proxy já está completamente funcional. Você pode começar a configurar os navegadores nos PCs da rede local para utilizá-lo e acompanhar o desempenho da rede.