Leia esta política em voz alta: permita que a rede do escritório use o proxy para o destino aprovado. Se essas condições andam juntas, mantenha-as juntas na regra.

http_access allow office_clients approved_destination

As duas ACL precisam corresponder para que essa linha permita a requisição. Dividi-la muda a política:

http_access allow office_clients
http_access allow approved_destination

Agora os clientes do escritório podem ser permitidos sem a restrição de destino, e as requisições para esse destino sem a restrição de escritório, a menos que uma regra anterior as tenha negado. Duas linhas não são uma grafia mais legível de uma linha.

A ordem faz parte da política

O Squid avalia as regras de acesso em sequência. A primeira decisão correspondente controla a requisição. Um allow all anterior anula uma restrição posterior cuidadosa; uma negação correspondente anterior impede alcançar uma permissão posterior.

A documentação do http_access explica essa sequência. Mantenha uma negação final deliberada em vez de confiar que o leitor lembre o comportamento padrão implícito.

Muitas definições de ACL têm uma relação OR diferente: uma ACL de origem nomeada pode listar vários intervalos permitidos. Isso não torna a identidade de origem e destino o mesmo tipo de ACL. Defina-as separadamente e depois combine os nomes numa decisão de acesso.

Para uma saída privada, isso afeta quem pode usar o seu IP externo. Considere quatro casos: cliente aprovado para destino aprovado, cliente aprovado para outro lugar, outro cliente para o destino aprovado e outro cliente para outro lugar. Se as regras permitem mais casos do que a política pretende, corrija a lógica antes de ampliar o ouvinte. Uma configuração sintaticamente válida ainda pode expressar permissões erradas.

Artigos relacionados