Combinar myportname e src de Squid con ACL separadas

A configuración parece plausible a primeira vista:

acl team_a myportname 3128 src 198.51.100.0/24

Pero unha definición de ACL ten un só tipo. Aquí myportname é o tipo; engadir a palabra src non inicia unha segunda comprobación. As palabras restantes pertencen á lista de valores do primeiro tipo. Esa liña non expresa «este listener e esta rede de clientes».

Darlle un nome a cada condición

Usa un nome para o socket de escoita e unha ACL de orixe separada. Este extracto emprega enderezos de documentación, que deben substituírse por enderezos axeitados ao despregamento:

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

Coloca a regra de permiso despois das proteccións existentes para portos de destino inseguros, obxectivos CONNECT restrinxidos e acceso de administración. O extracto ilustra a condición cliente/listener; non substitúe esas proteccións.

As condicións dunha liña http_access combínanse con AND. Dúas liñas de permiso separadas admitirían cada condición de forma independente, o que cambiaría bastante a política. Varios valores dentro dunha ACL adoitan ofrecer alternativas para esa única comprobación.

Escoller a saída por separado

Un listener coincidente tamén se pode usar con tcp_outgoing_address para escoller un enderezo de orixe local. Iso é selección de encamiñamento, non permiso para usar o proxy. Unha regra de enderezo de saída non pode facer que unha petición denegada pase por http_access.

Se unha configuración con varios enderezos deixa de funcionar tras unha actualización, separa as probas: un erro de análise apunta á sintaxe da configuración; unha denegación de acceso apunta á coincidencia de regras; unha petición permitida coa saída incorrecta apunta á selección de saída ou a un NAT posterior. Cambiar as tres cousas á vez fai que un pequeno erro de ACL sexa moito máis difícil de atopar.