Combinar myportname e src do Squid com ACL separadas

A configuração parece plausível à primeira vista:

acl team_a myportname 3128 src 198.51.100.0/24

Mas uma definição de ACL tem um só tipo. Aqui myportname é o tipo; acrescentar a palavra src não inicia um segundo teste. As palavras restantes pertencem à lista de valores do primeiro tipo. Essa linha não expressa «este listener e esta rede de clientes».

Dar um nome a cada condição

Use um nome para o socket de escuta e uma ACL de origem separada. Este trecho usa endereços de documentação, que devem ser substituídos por endereços adequados à implantação:

http_port 192.0.2.10:3128 name=team_a_port
acl team_a_port myportname team_a_port
acl team_a_clients src 198.51.100.0/24

http_access allow team_a_port team_a_clients
http_access deny all

Coloque a regra de permissão depois das proteções existentes para portas de destino inseguras, alvos CONNECT restritos e acesso administrativo. O trecho ilustra a condição cliente/listener; não substitui essas proteções.

As condições numa única linha http_access combinam-se com AND. Duas linhas de permissão separadas deixariam passar qualquer condição de forma independente, o que mudaria bastante a política. Vários valores dentro de uma ACL normalmente oferecem alternativas para esse único teste.

Escolher a saída separadamente

Um listener correspondente também pode ser usado por tcp_outgoing_address para escolher um endereço de origem local. Isso é seleção de rota, não permissão para usar o proxy. Uma regra de endereço de saída não consegue fazer um pedido recusado passar por http_access.

Se uma configuração com vários endereços deixar de funcionar após uma atualização, separe as evidências: um erro de análise aponta para a sintaxe da configuração; uma recusa de acesso aponta para a correspondência de regras; um pedido permitido com a saída errada aponta para a seleção de saída ou para NAT posterior. Mudar as três coisas ao mesmo tempo torna um pequeno erro de ACL muito mais difícil de encontrar.