Principais tipos de redes sem fio incluem:
| Cellular Digital Packet Data | ||
| High Speed Circuit de dados comutados | | |
| Packet dados celulares | ||
| General Packet Radio Service | ||
| 1x transmissão via rádio tecnologia | ||
| | ||
| | ||
| MMDS | ||
| Local Multipoint Distribution Service | ||
| Interoperabilidade mundial para acesso microondas | ||
| Wi-Fi | ||
| | | |
Access Point
Access Point ou AP ,
Pontos de acesso Wi-Fi estão se tornando populares. Muitos estabelecimentos comerciais que oferecem o acesso a internet através de um ponto de acesso como serviço ou cortesia aos clientes, tornando-se hotspots. Também é prático pois a implantação de uma rede sem fio interligada por um ponto de acesso economiza o trabalho de instalar a infra-estrutura cabeada.
Vários pontos de acesso podem trabalhar em conjunto para prover um acesso em uma área maior. Esta área é subdividida e áreas menores sendo cada uma delas coberta por um ponto de acesso, provendo acesso sem interrupções ao se movimentar entre as áreas através de roaming. Também pode ser formada uma rede ad-hoc onde os dispositivos móveis passam a agir intermediando o acesso dos dispositivos mais distantes ao ponto de acesso caso ele não possa alcançá-lo diretamente.
Estes pontos de acesso precisam implementar a segurança da comunicação entre eles e os dispositivos móveis que estão
O que é?
A tecnologia wireless (sem fios) permite a conexão entre diferentes pontos sem a necessidade do uso de cabos - seja ele telefônico, coaxial ou óptico - por meio de equipamentos que usam radiofrequência (comunicação via ondas de rádio) ou comunicação via infravermelho, como em dispositivos compatíveis com IrDA.
Wireless é uma tecnologia capaz de unir terminais eletrônicos, geralmente computadores, entre si devido às ondas de rádio ou infravermelho, sem necessidade de utilizar cabos de conexão entre eles. O uso da tecnologia wireless vai desde transceptores de rádio como walkie-talkies até satélites artificais no espaço.
Seu uso mais comum é em redes de computadores, onde a grande maioria dos usuários utiliza-se da mesma para navegar pela Internet no escritório, em um bar, um aeroporto, um parque, em casa, etc. Uma rede de computadores sem fios são redes que utilizam ondas eletromagnéticas ao invés de cabos, tendo sua classificação baseada na área de abrangência delas: redes pessoais ou curta distância (WPAN), redes locais (WLAN), redes metropolitanas (WMAN) e redes geograficamente distribuídas ou de longa distância (WWAN).
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.
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
Aqui eu criei 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, estou usando o arquivo "/etc/squid/bloqueados":
acl bloqueados url_regex -i "/etc/squid/bloqueados"
http_access deny bloqueados
Naturalmente, 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, que veremos mais adiante) e bloquear os sites mais acessados, conforme tomar conhecimento deles. É sempre uma corrida de gato e rato, mas, em se tratando de pessoas adultas, não há nada que uma boa conversa com o chefe não possa resolver. ;)
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 coloquei 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. Para criar filtros baseados no conteúdo, você pode utilizar o DansGuardian, que veremos mais adiante.
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
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.
Uma das configurações mais importantes com relação ao desempenho do proxy e à otimização do tráfego da rede é a configuração dos caches, onde o Squid guarda as páginas e arquivos já acessados de forma a fornecê-los rapidamente quando solicitados novamente. O Squid trabalha com dois tipos de cache:
1- Cache rápido, feito usando parte da memória RAM do servidor;
2- Cache um pouco mais lento porém maior, feito no HD.
O cache na memória RAM é ideal para armazenar arquivos pequenos, como páginas html e imagens, que serão entregues instantaneamente para os clientes. O cache no HD é usado para armazenar arquivos maiores, como downloads, arquivos do Windows Update e pacotes baixados via apt-get.
O cache na memória RAM é sempre relativamente pequeno, já que o volume de memória RAM no servidor é sempre muito menor do que o espaço
A configuração do cache é feita adicionando mais algumas linhas no arquivo de configuração:
1- A configuração da quantidade de memória RAM dedicada ao cache é feita adicionando a opção "cache_mem", que contém a quantidade de memória que será dedicada ao cache. Para reservar 64 MB, por exemplo, a linha ficaria:
cache_mem 64 MB
Como regra geral, você pode reservar 32 ou 64 MB para o cache em um servidor não dedicado, que atende a apenas alguns micros (como o servidor de uma pequena rede local) e até 1/3 da memória RAM total em um servidor proxy dedicado, que atende a um volume maior de usuários (veja mais detalhes a seguir). Em um servidor com 1 GB de RAM, por exemplo, você poderia reservar até 350 MB para o cache na memória.
2- Logo depois vai a opção "maximum_object_size_in_memory", que determina o tamanho máximo dos arquivos que serão guardados no cache feito na memória RAM (o resto vai para o cache feito no HD). O cache na memória é muito mais rápido, mas como a quantidade de RAM é muito limitada, é melhor deixá-la disponível para páginas web, figuras e arquivos pequenos
maximum_object_size_in_memory 64 KB
3- Em seguida vem a configuração do cache em disco, que armazenará o grosso dos arquivos. Por default, o máximo são downloads de até 16 MB e o mínimo é zero, o que faz com que mesmo imagens e arquivos pequenos sejam armazenados no cache. Quase sempre é mais rápido ler a partir do cache do que baixar de novo da web, mesmo que o arquivo seja pequeno.
Se você faz download de arquivos grandes com freqüência e deseja que eles fiquem armazenados no cache, aumente o valor da opção "maximum_object_size". Isso é especialmente útil para quem precisa baixar muitos arquivos através do apt-get ou Windows Update em muitos micros da rede. Se você quiser que o cache armazene arquivos de até 512 MB, por exemplo, as linhas ficariam:
maximum_object_size 512 MB
minimum_object_size 0 KB
Você pode definir ainda a percentagem de uso do cache que fará o Squid começar a descartar os arquivos mais antigos. Por padrão, sempre que o cache atingir 95% de uso, serão descartados arquivos antigos até que a percentagem volte para um número abaixo de 90%:
cache_swap_low 90
cache_swap_high 95
4- Depois vem a opção "cache_dir", que é composta por quatro valores. O primeiro, (/var/spool/squid) indica a pasta onde o Squid armazena os arquivos do cache, enquanto o segundo (2048) indica a quantidade de espaço no HD (em MB) que será usada para o cache. Aumente o valor se você tem muito espaço no HD do servidor e quer que o Squid guarde os downloads por muito tempo.
Continuando, os números 16 e 256 indicam a quantidade de subpastas que serão criadas dentro do diretório. Por padrão, temos 16 pastas com 256 subpastas cada uma. O número "ideal" de pastas e subpastas para um melhor desempenho varia de acordo com o sistema de arquivos usado, mas esta configuração padrão é adequada para a maioria das situações. Combinando as quatro opções, a linha ficaria:
cache_dir ufs /var/spool/squid 2048 16 256
Assim como na maioria das opções do Squid, se a linha "cache_dir" for omitida, é usada a configuração default para a opção, que é usar o diretório "/var/spool/squid" e fazer um cache em disco de 100 MB.
5- Você pode definir ainda o arquivo onde são guardados os logs de acesso do Squid. Por padrão, o Squid guarda o log de acesso no arquivo "/var/log/squid/access.log". Este arquivo é usado pelo Sarg para gerar as páginas com as estatísticas de acesso:
cache_access_log /var/log/squid/access.log
Mais uma configuração que você pode querer alterar é o padrão de atualização do cache. Estas três linhas precisam sempre ser usadas em conjunto, ou seja, você pode alterá-las, mas sempre as três precisam estar presentes no arquivo. Eliminando uma, o Squid ignora as outras duas e usa o default.
Os números indicam o intervalo (em minutos) que o Squid irá aguardar antes de verificar se um item do cache (uma página, por exemplo) foi atualizado, para cada um dos três protocolos. O primeiro número (o 15) indica que o Squid verificará (a cada acesso) se as páginas e arquivos com mais de 15 minutos foram atualizados. Ele faz uma verificação rápida, checando o tamanho do arquivo e, se o arquivo não mudou, ele continua fornecendo aos clientes o arquivo que está no cache, economizando banda da conexão
O terceiro número (o 2280, equivalente a dois dias) indica o tempo máximo, depois do qual o objeto é sempre verificado. Além do http e ftp, o Squid suporta o protocolo gopher, que era muito usado nos primórdios da internet para localizar documentos de texto, mas perdeu a relevância hoje em dia:
refresh_pattern ^ftp: 15 20% 2280
refresh_pattern ^gopher: 15 0% 2280
refresh_pattern . 15 20% 2280
Depois de adicionar todas estas configurações, o nosso arquivo de configuração já ficará bem maior:
http_port 3128
visible_hostname gdh
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 redelocal src 192.168.1.0/24
http_access allow localhost
http_access allow redelocal
http_access deny all
Aqui já temos uma configuração mais completa, incluindo um conjunto de regras de segurança (para que o proxy seja usado apenas a partir da rede local) e a configuração do cache. Esta é uma configuração adequada para uso em uma rede doméstica ou em um pequeno escritório.
A acl "Safe_ports", alimentada com um conjunto de portas (80, 21 e outras) é usada para restringir as portas de saída do servidor proxy, evitando, por exemplo, que ele seja usado para enviar e-mails (porta 25). Isso evita um conjunto de abusos comuns e é uma configuração importante em qualquer servidor que precise ser configurado de forma minimamente segura. Naturalmente, você pode adicionar outras portas à lista, conforme necessário.
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 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.1.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:
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.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 localhost
http_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/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
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.
