segunda-feira, 7 de novembro de 2011

Fazendo hierarquia proxy/Squid

Hierarquia é um recurso muito interessante, principalmente para redes grandes, onde o tráfego de informação é muito intenso e apenas um proxy poderia ser muito pouco, então com este recurso você acaba por desatolar o servidor proxy/Squid de ter que fazer todo o trabalho, passando a tarefa para mais de um e tendo assim o melhor desempenho do proxy/Squid.

O proxy/Squid por si já é um servidor muito poderoso, não é à toa que é o mais usado, ele consegue desempenhar sozinho tarefas que seriam muito pesadas para outros servidores e até mesmo funções de outros programas, como a resolução de nomes (que é função do DNS fazer), isso é só para se ter uma idéia do poder do proxy/Squid, então se for escolher um proxy, tem que ser o Squid.

Opções para fazer "hierarquia proxy"

Primeiro habilite a porta ICP em ambos os servidores (o padrão é 3130):

icp_port [número da porta icp]

Agora coloque a opção que colocará nossa hierarquia de pé:

cache_peer

Especifica outros caches na hierarquia. A opção cache_peer é dividida em 5 campos, e sua saída é a seguinte.

cache_peer x.x.x.x parent 3128 3130 no-digest no-netbd-exchange

Onde:
  • x.x.x.x - o IP ou nome da máquina que será pesquisada.
  • parent - o relacionamento com o outro servidor (veja bibliografia).
  • 3128 - a porta HTTP.
  • 3130 - a porta ICP (que é quem faz as requisições).
  • o restante são as opções (que podem conter zero ou uma palavra chave). (veja bibliografia).

Há também uma opção chamada hierarchy_stoplist, comente ela. Se esta opção estiver ativada, o proxy/Squid não conseguirá fazer a hierarquia de cache.

Uma lista de palavras que, encontradas na URL, farão com que o objeto seja manipulado automaticamente por esse cache:

hierarchy_stoplist cgi-bin ?

A ACL aqui é só para colocarmos junto com a opção "no_cache". Depois faça o seguinte, por padrão o Squid cria uma ACL chamada "all". Esta ACL engloba toda sua rede, se ela não existir crie uma:

acl all(pode ser outro nome) src 0.0.0.0/0.0.0.0

Com esta opção você cria uma ACL, onde se encontrado não será feito o cache:

no_cache deny all (tem que ser o mesmo nome de nossa acl "all")

Depois dê permissão para ela com a opção http_access. Esta opção permitirá que nossa ACL seja manipulada pelo Squid:

http_access allow all


Como Tudo Ficaria

Você terá dois servidores proxy/Squid, por exemplo, um com o IP 1.1.1.1 e outro com o IP 1.1.1.2. Suponha que o servidor 1 (1.1.1.1) escutará o 2 (1.1.1.2), então a saída no log do servidor 2 (/var/log/squid/access.log) deve ser mais ou menos assim:

"1086316383.840 3 1.1.1.1 TCP_DENIED/403 1417 GET http://www.nome de alguma pag.com.br/checker.php - NONE/- text/html
1086316407.347 0 1.1.1.1 UDP_MISS/000 71 ICP_QUERY http://www.nome de alguma pag.com.br/index.php?task=logout - NONE/- -
1086316407.353 3 1.1.1.1 TCP_DENIED/403 1415 GET http://www.nome de alguma pag.com.br/index.php? - NONE/- text/html
1086316407.358 5 1.1.1.1 TCP_DENIED/403 1415 GET http://www.nome de alguma pag.com.br/index.php? - NONE/- text/html"

Isso quer dizer que o servidor 1 está escutando o servidor 2. Vejam na linha depois do endereço IP a mensagem "ICP_QUERY".

Bem, no arquivo squid.conf, a ordem das configurações sairia mais ou menos assim:

icp_port 3130

#hierarchy_stoplist cgi-bin ? #<-- linha comentada.
cache_peer 1.1.1.2 parent 3128 3130 no-digest no-netdb-exchange
acl all src 0.0.0.0/0.0.0.0
no_cache deny all

http_access allow all

Bibliografia: Linuxman, Under-linux 

Esse conteúdo está disponibilizado sobre a licença de uso - Tiu enhavo estas disponebla sur uza permesilo LiPE

Um comentário:

  1. Existe uma forma do servidor 1 repassar os endereços IP dos seus requisitantes para o servidor 2, de tal forma que o log do servidor 2 mostre os IP de origem e não o IP do servidor 1?

    ResponderExcluir

Postagens populares