O Squid é um software especializado em fazer a operaçãoo de proxy de web e ftp, completamente free e com excelente suporte para operaçãoo em servidores Linux.

Com o Squid você pode instalar um servidor Linux com acesso a Internet, e fazer com que outras máquinas clientes (usando Linux, Windows ou outro sistema operacional) acessem páginas web e sites ftp através do servidor Linux, mesmo que estas máquinas clientes não tenham conexão direta com a internet. Tudo que elas precisam é o acesso ao próprio servidor onde está rodando o Squid.

A única configuração necessária na máquina cliente é feita no próprio browser: você precisa definir qual o endereço do servidor proxy. Esta é uma operação bastante simples, disponível nos menus do Netscape, do Internet Explorer e dos demais browsers em geral.

Comando para instalar o Squid no Fedora ou distribuições similares:

#yum install squid
Toda a configuração do Squid é feita em um único arquivo, o /etc/squid/squid.conf”.

 

Configurando o Squid de forma simplificada

Em primeiro lugar vamos renomear o arquivo padrão, de forma a conservá-lo para fins de pesquisa:

# mv /etc/squid/squid.conf /etc/squid/squid.conf.orig

 

Em seguida, crie um novo arquivo “/etc/squid/squid.conf”, contendo apenas as quatro linhas abaixo:

http_port 3128
visible_hostname gdh
acl all src 0.0.0.0/0.0.0.0
http_access allow all

Estas linhas são o suficiente para que o Squid “funcione”

 

Entendendo a configuração acima


http_port 3128
: A porta onde o servidor Squid vai ficar disponível. A porta 3128 é o default, mas muitos administradores preferem utilizar a porta 8080, que soa mais familiar a muitos usuários.

visible_hostname gdh: O nome do servidor, o mesmo que foi definido na configuração da rede. Ao usar os modelos desse capítulo, não se esqueça de substituir o “gdh” pelo nome correto do seu servidor, como informado pelo comando “hostname”.

acl all src 0.0.0.0/0.0.0.0http_access allow all: Estas duas linhas criam uma acl (uma política de acesso) chamada “all” (todos), incluindo todos os endereços IP possíveis. Ela permite que qualquer um dentro desta lista use o proxy, ou seja, permite que qualquer um use o proxy, sem limitações.

Para testar a configuração, reinicie o servidor Squid com o comando:

/etc/init.d/squid restart

Se estiver no CentOS, Fedora ou Mandriva, pode utilizar o comando “service”, que economiza alguns toques no teclado:

# service squid restart

Para testar o proxy, configure um navegador (no próprio servidor) ou qualquer outra máquina da mesma rede para usar o proxy, através do endereço 127.0.0.1 (o localhost), porta 3128. Se não houver nenhum firewall pelo caminho, você conseguirá acessar o proxy também através dos outros micros da rede local, basta configurar os navegadores para usarem o proxy, fornecendo o endereço do servidor na rede local.

Para confirmarmos se estamos navegando pelo nosso squid, vamos pará-lo para ver se a navegação também irá parar.

Caso necessário, abra a porta 3128 na configuração do firewall, para que o Squid possa receber as conexões. Um exemplo de regra manual do Iptables para abrir a porta do Squid apenas para a rede local (a interface eth0 no exemplo) é:

iptables -A INPUT -i eth0 -p tcp –dport 3128 -j ACCEPT

 

Criando uma configuração básica

O problema com o modelo de configuração simplificada 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 conhecer agora, uma configuração mais completa, permitindo que apenas os micros da rede local possam usar o proxy e definindo mais algumas políticas de segurança. Neste segundo exemplo iremos aproveitar 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 3128
visible_hostname gdh

acl all src 0.0.0.0/0.0.0.0
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl SSL_ports port 443 563
acl Safe_ports port 80 # http
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 563 # https, snews
acl Safe_ports port 70 # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 280 # http-mgmt
acl Safe_ports port 488 # gss-http
acl Safe_ports port 591 # filemaker
acl Safe_ports port 777 # multiling http
acl Safe_ports port 901 # swat
acl Safe_ports port 1025-65535 # portas altas
acl purge method PURGE
acl CONNECT method CONNECT

http_access allow manager localhost
http_access deny manager
http_access allow purge localhost
http_access deny purge
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports

acl redelocal src 192.168.11.0/24
http_access allow localhost
http_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. Exemplo:

http_port 3128
visible_hostname gdh

acl all src 0.0.0.0/0.0.0.0
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl SSL_ports port 443 563
acl Safe_ports port 21 80 443 563 70 210 280 488 59 777 901 1025-65535
acl purge method PURGE
acl CONNECT method CONNECT

http_access allow manager localhost
http_access deny manager
http_access allow purge localhost
http_access deny purge
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports

acl redelocal src 192.168.1.0/24
http_access allow localhost
http_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.11.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.
Lembra 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/24
http_access allow redelocal
http_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.com
always_direct allow site

Esta regra deve vir antes da regra que libera os acessos provenientes da rede local, como em:

acl site dstdomain siteproblematico.com
always_direct allow site

acl redelocal src 192.168.1.0/24
http_access allow localhost
http_access allow redelocal
http_access deny all

Sempre após configurar o arquivo, o serviço deve ser reiniciado para que a configuração entre em vigor:

# /etc/init.d/squid restart

Desta forma 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. Agora que já vimos o padrão/ básico, vamos aos detalhes mais avançados da configuração:

 

Adicionando restrições de acesso

Em um ambiente de trabalho, a idéia é que os funcionários usem a internet para comunicação, pesquisa e outras funções relacionadas ao que estão fazendo. Muitas empresas permitem que sejam acessados os e-mails pessoais e coisas do gênero, mas sempre até um certo limite. Chegamos então às regras para restrição de acesso, que são uma necessidade em muitas redes.

 

Bloqueando por domínios ou palavras

O Squid permite bloquear sites indesejados de forma bastante simples usando o parâmetro “dstdomain”. Ele permite que você crie acl’s contendo endereços de sites que devem ser bloqueados (ou permitidos). Isso é feito em duas etapas. Primeiro você cria a acl, especificando os endereços e, em seguida, usa o parâmetro “http_access” para bloquear ou liberar o acesso a eles. Veja um exemplo:

acl bloqueados dstdomain orkut.com playboy.abril.com.br
http_access deny bloqueados

Neste exemplo foi criado uma acl chamada “bloqueados“, que contém os endereços “orkut.com” e “playboy.abril.com.br” e em seguida usei o parâmetro “http_access deny” para bloquear o acesso a eles. Você pode incluir diversas acls diferentes dentro da configuração do Squid, desde que use um nome diferente para cada uma. De certa forma, elas são similares às variáveis, que usamos ao programar em qualquer linguagem.

Ao aplicar a regra, o Squid faz a resolução do domínio e passa a bloquear todas sub-páginas que estiverem hospedadas dentro dele. Existe uma ressalva: muitos sites podem ser acessados tanto com o “www” quanto sem. Se os dois estiverem hospedados em servidores diferentes, o Squid considerará que tratam-se de dois sites diferentes, de forma que ao bloquear apenas o “www.orkut.com” os usuários ainda conseguirão acessar o site através do “orkut.com” e vice-versa. Nesses casos, para bloquear ambos, é preciso incluir as duas possibilidades dentro da regra, como em:

acl bloqueados dstdomain orkut.com www.orkut.com playboy.abril.com.br
http_access deny bloqueados

Você pode incluir quantos domínios quiser dentro da acl, basta separá-los por espaço e deixar tudo na mesma linha. Se a regra começar a ficar muito grande, você tem a opção de transferir as entradas para um arquivo. Nesse caso, crie um arquivo de texto simples, com todos os domínios desejados (um por linha), como em:

orkut.com
www.orkut.com
playboy.abril.com.br
www.myspace.com

… e use a regra abaixo na configuração do Squid para que ele seja processado e os domínios sejam incluídos na acl. No exemplo, foi utilizado o arquivo /etc/squid/bloqueados”:

acl bloqueados url_regex -i “/etc/squid/bloqueados”
http_access deny bloqueados

Ná prática, não seria viável tentar bloquear manualmente todos os sites pornográficos, chats, comunidades online, e todos os outros tipos de sites que não são  úteis em um ambiente de trabalho. A idéia seria logar os acessos (com a ajuda do Sarg, ou ferramentas similares) e bloquear os sites mais acessados, conforme tomar conhecimento deles.

De qualquer forma, em alguns ambientes pode ser mais fácil bloquear inicialmente o acesso a todos os sites e ir abrindo o acesso a apenas alguns sites específicos, conforme a necessidade. Neste caso, invertemos a lógica da regra. Criamos um arquivo com sites permitidos, adicionamos a regra que permite o acesso a eles e em seguida bloqueamos o acesso a todos os demais, como neste exemplo:

acl permitidos url_regex -i “/etc/squid/permitidos”
http_access allow permitidos
http_access deny all

Nas versões recentes do Squid, ao bloquear um domínio é automaticamente bloqueado também o endereço IP do servidor correspondente. Isso evita que os usuários da rede consigam burlar o proxy, acessando os sites diretamente pelo IP. De qualquer forma, você pode criar diretamente regras que bloqueiem determinados endereços IP, o que é útil em casos de servidores sem domínio registrado, ou que respondam por vários domínios. Nesse caso, a regra ficaria:

acl ips-bloqueados dst 200.234.21.23 200.212.15.45
http_access deny ips-bloqueados

Você pode descobrir rapidamente o endereço IP de um determinado domínio usando o comando “host“, como em: $ host google.com

google.com A 72.14.207.99
google.com A 64.233.187.99
google.com A 64.233.167.99

Depois de adicionar as novas regras, nosso arquivo de configuração ficaria assim:

http_port 3128
visible_hostname gdh
error_directory /usr/share/squid/errors/Portuguese/

cache_mem 64 MB
maximum_object_size_in_memory 64 KB
maximum_object_size 512 MB
minimum_object_size 0 KB
cache_swap_low 90
cache_swap_high 95
cache_dir ufs /var/spool/squid 2048 16 256
cache_access_log /var/log/squid/access.log
refresh_pattern ^ftp: 15 20% 2280
refresh_pattern ^gopher: 15 0% 2280
refresh_pattern . 15 20% 2280

acl all src 0.0.0.0/0.0.0.0
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl SSL_ports port 443 563
acl Safe_ports port 21 80 443 563 70 210 280 488 59 777 901 1025-65535
acl purge method PURGE
acl CONNECT method CONNECT

http_access allow manager localhost
http_access deny manager
http_access allow purge localhost
http_access deny purge
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports

acl bloqueados url_regex -i “/etc/squid/bloqueados”
http_access deny bloqueados

acl redelocal src 192.168.1.0/24
http_access allow localhost
http_access allow redelocal
http_access deny all

Veja que neste exemplo foi utilizado as duas regras antes do “http_access allow redelocal”, que abre tudo para a rede local. Como o Squid processa as regras seqüencialmente, as páginas que forem bloqueadas pela acl “bloqueados” não chegam a passar pela regra que autoriza os acessos provenientes da rede local.

Uma segunda possibilidade é usar o parâmetro “dstdom_regex”, que permite bloquear sites de uma forma mais geral, com base em palavras incluídas na URL de acesso. Você pode bloquear todas as páginas cujo endereço inclua a palavra “sexo” ou “orkut”, por exemplo. Note que, ao usar esta regra, o Squid verifica a existência das palavras apenas na URL do site e não no conteúdo da página.

Crie mais um arquivo de texto, contendo as palavras que devem ser bloqueadas, uma por linha, como em:

orkut
xxx
sexo
teens
warez

… e adicione a regra abaixo, contendo a localização do arquivo:

acl palavrasproibidas dstdom_regex “/etc/squid/palavrasproibidas”
http_access deny palavrasproibidas

O uso desta regra é um pouco mais problemático, pois bloqueará todas páginas que contenham qualquer uma das palavras listadas na URL. Esta opção sempre levará a alguns falsos positivos e por isso deve ser usada com mais cuidado.

Uma vantagem é que ela permite bloquear facilmente páginas dinâmicas, onde a palavra é passada como parâmetro da URL. Um exemplo é o Orkut, onde, depois da transferência para o Google, os domínios principais passaram a encaminhar para URLs dinâmicas dentro do domínio do Google, como em:

https://www.google.com/accounts/ServiceLogin?service=orkut&continue=http%3A%2F%2Fwww.orkut.com
%2FRedirLogin.aspx%3Fmsg%3D0%26page%3Dhttp%253A%252F%252F
www.orkut.com%252FHome.aspx&hl=pt-BR&rm=false&passive=true

Você não poderia simplesmente bloquear o domínio “google.com” usando uma regra url_regex, mas poderia muito bem usar o dstdom_regex para bloquear a palavra “orkut” e assim bloquear o acesso ao site sem bloquear o acesso a outros serviços do Google.

Não existe problema em combinar o bloqueio de domínios e de palavras dentro da URL, você pode lançar mão de uma combinação das duas coisas, de acordo com a situação. Para isso, basta usar as duas regras simultaneamente, como em:

acl bloqueados url_regex -i “/etc/squid/bloqueados”
http_access deny bloqueados

acl palavrasproibidas dstdom_regex “/etc/squid/palavrasproibidas”
http_access deny palavrasproibidas

acl redelocal src 192.168.1.0/24
http_access allow localhost
http_access allow redelocal
http_access deny all

 

Incluídas as regras, os clientes passam a ver uma mensagem de erro ao tentar acessar páginas que se enquadrem nos bloqueios.

Por padrão, as mensagens de erro aparecerem em inglês. No nosso caso elas estão aparecendo em português devido à linha “error_directory /usr/share/squid/errors/Portuguese/” que incluí no exemplo de configuração anterior.

Você pode personalizar as páginas de erro editando os arquivos dentro da pasta “/usr/share/squid/errors/Portuguese” ou “/usr/share/squid/errors/English” (de acordo com a língua definida na configuração). A pasta contêm várias páginas html, uma para cada tipo de erro indicado.


Bloqueando por horário

As regras a seguir fazem com que o proxy aceite ou recuse conexões feitas dentro de determinados horários. Você pode definir regras para períodos específicos e combiná-las para bloquear todos os horários em que você não quer que o proxy seja usado ou vice-versa. Para que o proxy bloqueie acessos feitos entre meia-noite e 6:00 da manhã e no horário de almoço, por exemplo, você usaria as regras:

acl madrugada time 00:00-06:00
http_access deny madrugada

acl almoco time 12:00-14:00
http_access deny almoco

Estas regras iriam, novamente, antes da regra “http_access allow redelocal” no arquivo de configuração.

Agora, imagine que você quer fazer diferente. Ao invés de bloquear o acesso na hora de almoço, você quer deixar o proxy aberto, para que aqueles que queiram acessar o Orkut ou acessar os e-mails possam fazer isso fora do horário de trabalho. Neste caso, você usaria uma regra como:

acl almoco time 12:00-14:00
http_access allow almoco

Esta regra entraria no arquivo de configuração antes das regras “http_access deny bloqueados” e outras restrições. Assim, os acessos que forem aceitos pela regra do almoço não passarão pelas regras que fazem o bloqueio, como em:

acl almoco time 12:00-14:00

http_access allow almoco

acl bloqueados url_regex -i “/etc/squid/bloqueados”
http_access deny bloqueados
acl extban url_regex -i “/etc/squid/extban”
http_access deny extban

acl redelocal src 192.168.1.0/24
http_access allow localhost
http_access allow redelocal
http_access deny all

Você pode também combinar o bloqueio de palavras ou domínio com as regras de bloqueio por horário, permitindo que os usuários acessem um determinado site apenas no horário de almoço, por exemplo. Neste caso, a regra seria:

acl almoco time 12:00-14:00
acl orkut dstdomain orkut.com www.orkut.com
http_access allow orkut almoco
http_access deny orkut

Fazendo isso, o Squid entende que os endereços incluídos dentro da acl “orkut” devem ser permitidos, mas apenas dentro do horário especificado na acl “almoco”. Em seguida é incluída mais uma regra, que bloqueia o acesso ao site em outros horários.

 

Gerenciando o uso da banda

O Squid oferece uma forma simples de limitar o uso da banda disponível e definir o quanto cada usuário pode usar (mantendo parte do link livre para os demais), utilizando um recurso chamado “delay pools”. Imagine, por exemplo, que você tem um link de 1 megabit para uma rede com 20 usuários. Se cada um puder ficar baixando o que quiser, é provável que a rede fique saturada em determinados horários, deixando a navegação lenta para todo mundo.

Você pode evitar isso limitando a banda que cada usuário pode usar e a banda total, que todos os usuários somados poderão usar simultaneamente. É recomendável, neste caso, que o servidor proxy (que combina todos os acessos via http) consuma um pouco menos que o total de banda disponível, de forma a sempre deixar um pouco reservado para outros protocolos.

Um link de 1 megabit (1024 kbits) corresponde a 131.072 bytes por segundo. Nas regras do Squid, sempre usamos bytes, por isso lembre-se de fazer a conversão, dividindo o valor em kbits por 8 e multiplicando por 1024 para ter o valor em bytes.

Podemos, por exemplo, limitar a banda total usada pelo Squid a 114.688 bytes por segundo, deixando 128 kbits do link livres para outros protocolos e limitar cada usuário a no máximo 16.384 bytes por segundo, que correspondem a 128 kbits. Nem todos os usuários vão ficar baixando arquivos a todo momento, por isso o valor ideal reservado a cada usuário vai variar muito de acordo com a rede. Você pode acompanhar o uso do link e ir ajustando o valor conforme a utilização.

Neste caso, a parte final do arquivo de configuração ficaria:

acl redelocal src 192.168.1.0/24
delay_pools 1
delay_class 1 2

delay_parameters 1 114688/114688 16384/16348
delay_access 1 allow redelocal
http_access allow localhost
http_access allow redelocal
http_access deny all

A acl “redelocal” está agora condicionada a três novas regras, que aplicam o uso do limite de banda. O acesso continua sendo permitido, mas agora dentro das condições especificadas na linha “delay_parameters 1 114688/114688 16384/16384”, onde vão (respectivamente) os valores com a banda total disponível para o Squid e a banda disponível para cada usuário.

Veja que nessa regra foi limitado a banda apenas para a acl “redelocal” e não para o “localhost”. Isso significa que você continua conseguindo fazer downloads na velocidade máxima permitida pelo link ao acessar a partir do próprio servidor; a regra se aplica apenas às estações.

É possível também criar regras de exceção para endereços IP específicos, que poderão fazer downloads sem passar pelo filtro. Nesse caso, criamos uma acl contendo o endereço IP da estação que deve ter o acesso liberado usando o parâmetro “src” e a colocamos antes da regra que limita a velocidade, como em:

acl chefe src 192.168.1.2
http_access allow chefe

acl redelocal src 192.168.1.0/24
delay_pools 1
delay_class 1 2
delay_parameters 1 114688/114688 16384/16348
delay_access 1 allow redelocal
http_access allow localhost
http_access allow redelocal
http_access deny all

Esta regra de exceção pode der usada também em conjunto com as demais regras de restrição de acesso que vimos anteriormente. Basta que a acl com o IP liberado seja colocada antes das acls com as restrições de acesso, como em:

acl chefe src 192.168.1.2

http_access allow chefe

acl bloqueados url_regex -i “/etc/squid/bloqueados”
http_access deny bloqueados
acl palavrasproibidas dstdom_regex “/etc/squid/palavrasproibidas”
http_access deny palavrasproibidas

acl redelocal src 192.168.1.0/24
http_access allow localhost
http_access allow redelocal
http_access deny all

Concluindo, mais um tipo de bloqueio útil em muitas situações é com relação a formatos de arquivos. Você pode querer bloquear o download de arquivos .exe ou .sh
para dificultar a instalação de programas nas estações, ou bloquear arquivos .avi ou .wmv para economizar banda da rede, por exemplo.

Neste caso, você pode usar a regra a seguir, especificando as extensões de arquivo desejadas. Ela utiliza o parâmetro “url_regex” (o mesmo que utilizamos para
criar o bloqueio de domínios), dessa vez procurando pelas extensões de arquivos especificadas:

acl extban url_regex -i \.avi \.exe \.mp3 \.torrent
http_access deny extban

Esta regra aceita também o uso de um arquivo externo, de forma que se a lista começar a ficar muito grande, você pode migrá-la para dentro de um arquivo de texto e especificar sua localização dentro da acl, como em:

acl extban url_regex -i “/etc/squid/extban”
http_access deny extban

Dentro do arquivo, você inclui as extensões desejadas (sem esquecer da barra invertida antes do ponto), uma por linha, como em:

\.avi
\.exe
\.mp3
\.torrent

Uma observação é que bloquear arquivos .torrent usando essa regra não impede que os usuários da rede utilizem o bittorrent, mas apenas que baixem os arquivos .torrent para iniciarem o download (o que acaba sendo o suficiente para fazer os usuários menos técnicos desistirem de baixar o arquivo). Para realmente bloquear o download de arquivos via bittorrent, é necessário bloquear diretamente os endereços dos trackers.

Continuando, sempre que fizer alterações na configuração, você pode aplicar as mudanças usando o comando:

# /etc/init.d/squid reload

Evite usar o “/etc/init.d/squid restart” em ambientes de produção, pois ele força um reinício completo do Squid, onde o proxy precisa finalizar todas as conexões abertas, finalizar todos os processos e desativar o cache, para só então ler a configuração e carregar todos os componentes novamente. Isso faz com que o proxy fique vários segundos (ou até minutos, de acordo com o número de clientes conectados a ele) sem responder conexões, fazendo com que o acesso fique fora do ar:

# /etc/init.d/squid restart

Restarting Squid HTTP proxy: squid Waiting…………………done.

O parâmetro “reload” permite que o Squid continue respondendo aos clientes e aplique a nova configuração apenas às novas requisições. Ele é suportado por diversos outros serviços onde o “restart” causa interrupção no serviço, como no caso do Apache.