Habilitar Debug no squid

Quando a configuração do seu squid passa a ficar cada vez mais complexa, o que geralmente resulta no crescimento do número de acls(ou seria o contrário? :P), é essencial utilizar o debug para obter mais detalhes sobre seu proxy.

O squid possui várias seções de debug, que podem ser habilitadas. A lista completa você pode ver aqui.

No meu caso, como estava precisando confirmar em qual acl determinado acesso estava sendo bloqueado, tive que habilitar o debug da seção 28, que trata sobre controle de acessos:

debug_options 28,2

Sendo que o 2, no final da configuração nada mais é que o log level que você necessita.

Ah! Muito cuidado ao habilitar o debug em um proxy que esteja em pleno funcionamento. O log pode crescer rapidamente, além do i/o para a escrita do log aumentar consideravelmente.

Até a próxima!

TCP_DENIED_REPLY/403 no access.log

A configuração de meu proxy possui uma acl que libera o acesso ao site xpto.

Apesar de haver uma acl explícita de liberação, que antecede qualquer outra acl de bloqueio e que talvez pudesse interferir nas permissões, o proxy estava retornando a mensagem TCP_DENIED_REPLY/403 ao tentar baixar um arquivo deste mesmo site xpto.

Geralmente, quando necessito liberar o acesso total a determinado site/domínio eu utilizo somente uma diretiva http_request liberando determinada acl.

Realmente não é necessário a utilização da diretiva http_reply_access, já que por padrão ela é uma diretiva permissiva:

 NOTE: if there are no access lines present, the default is to allow
 all replies

Porém, em minha configuração a diretiva http_reply_access já tinha sido utilizada para restringir um outro conteúdo. Exatamente este uso que passou a impactar esta liberação.

Para solucionar o problema e permitir que o cliente acessasse todo o conteúdo do site, bastou incluir a exceção para a acl do site que eu precisava liberar na chamada desta diretiva (http_reply_access).

Servidor DHCP ofertando endereço de uma reserva fixa

Cenário:
Servidor DHCP Linux com algumas reservas fixas (fixed-address) e outras estações adquirindo ips dinâmicos. Ambas configurações no mesmo range de ips.
Estações Linux e Windows XP

Problema:
Estação windows que recebe endereço fixo do servidor DHCP entrando em conflito com outra estação(Linux) que não possui uma reserva física.

Suspeita1:
Antes de disponibilizar um endereço à uma estação o servidor DHCP faz uma confirmação se alguém já está utilizando o endereço através do envio de pacotes ICMP. Obtendo resposta ele testa o próximo endereço até encontrar um endereço livre.
Estações com windows XP, por padrão, bloqueiam pacotes ICMP. Logo, o primeiro passo é liberar os pacotes icmp no firewall do windows e forçando o lease e a renovação das duas estações que estavam conflitando anteriormente.

Suspeita2:
Ao analisar os logs do servidor DHCP, notei que a renovação do endereço da estação com Windows XP não estava ocorrendo conforme a configuração padrão do servidor (2 em 2 horas), apesar dela ter ficado ligada e com a conexão física de rede em perfeitas condições todo este tempo.
Foi confirmado que esta estação estava ociosa por um bom período e que também estava com a opção que permite o desligamento da interface de rede em casos de ociosidade para economia de energia ativada.
Com esta opção desativada, a estação passou a fazer suas renovações de endereço conforme esperado e outras estações não receberam a oferta do endereço que havia sido previamente reservado.

Solução Ideal:
A solução ideal para o cenário apresentado ainda continua sendo a divisão do dhcp em pools de endereçamento. Assim você consegue delimitar os endereços que serão fornecidos dinamicamente dos que serão utilizados nas reservas fixas.