Una regla allow de Squid significa AND; dos pueden significar OR

Lee esta política en voz alta: permite que la red de la oficina use el proxy para el destino aprobado. Si esas condiciones van juntas, mantenlas juntas en la regla.

http_access allow office_clients approved_destination

Ambas ACL deben coincidir para que esa línea permita la petición. Dividirla cambia la política:

http_access allow office_clients
http_access allow approved_destination

Ahora los clientes de la oficina pueden permitirse sin la restricción de destino, y las peticiones a ese destino sin la restricción de oficina, salvo que una regla anterior las haya denegado. Dos líneas no son una forma más legible de escribir una.

El orden forma parte de la política

Squid evalúa las reglas de acceso en secuencia. La primera decisión coincidente controla la petición. Un allow all anterior anula una restricción posterior cuidadosa; una denegación coincidente anterior impide llegar a una permitida posterior.

La documentación de http_access explica esta secuencia. Mantén una denegación final deliberada en lugar de confiar en que el lector recuerde el comportamiento implícito por defecto.

Muchas definiciones de ACL tienen una relación OR distinta: una ACL de origen con nombre puede listar varios rangos permitidos. Eso no convierte la identidad de origen y destino en el mismo tipo de ACL. Defínelas por separado y luego combina los nombres en una decisión de acceso.

Para una salida privada, esto afecta a quién puede usar tu IP exterior. Considera cuatro casos: cliente aprobado hacia destino aprobado, cliente aprobado en otro lugar, otro cliente hacia el destino aprobado y otro cliente en otro lugar. Si las reglas permiten más casos de los que la política pretende, corrige la lógica antes de ampliar el oyente. Una configuración sintácticamente válida aún puede expresar permisos equivocados.