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 limitamos 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.
Nenhum comentário:
Postar um comentário