On 18/07/2016 6:23 p.m., B. Henry wrote: > First, thanks for answering. > Second, I have read the entire default conf file, yes, once made the mistake of reading one for a different squid version than mine, but then got a fresh > copy of the one for my exact version. > I've also read the FAQ, and most all the configuration guide, but if I had not I certainly would be greatful for the links. > My misunderstanding then is now in how to apply a rule that will only effect group foo with out reusing the name. > Would I first name the group as I have and then make a maxconn line, e.g. > acl foo_MC maxconn 15 > and then > http_access allow foo > http_access foo_MC > > and if this is correct, It is not correct as-is. The allow/deny action is missing on the foo_MC line. (Plus the logic mistake explained below.) > is it just the ordering there that means that this maxconn will only apply to group foo? No. The above config means the opposite of that. Top-to-bottom, left-to-right boolean conditions. # if foo, then Allow http_access allow foo # else if foo_MC, then ??? http_access ??? foo_MC # else if true, then deny http_access deny all foo_MC test will never be reached (and so not applied) for anything which is already Allow'ed by the "foo" ACL test. So logically, the foo_MC rule is applied (only) to non-"foo" traffic. > If not, how do I make the rule only apply to group foo? One would usually construct the access lists to enforce a logically arranged policy something like this: # 0) default security rules preventing various attacks http_access deny !Safe_ports http_access deny CONNECT !SSL_ports # 1) prevent foo from using more that 15 TCP connections to the proxy http_access deny foo foo_MC # 2) allow foo (with 15 or les connections) to use the proxy http_access allow foo # 3) allow LAN clients (not in group foo) to use the proxy http_access allow locanet # 4) deny other (external / non-LAN) traffic http_access deny all Any http_access line which contains 'foo' ACL can only match when that test of foo is a match, so that action on it by definition applies only to the set of transactions where foo is matched/true. Any http_access line which matches completely will halt http_access processing. So a line which contains only "foo" ACL and the action, will prevent any following lines being used for that group. The above two points/details are why the "deny foo foo_MC" line is ordered above the "allow foo" line in the above example config. --> If they were the other way around the "allow foo" would end the processing for "foo" group with an allow action. The any line containign "foo" after that would never be a match for anything that could reach it. PS. there is a gotcha with the maxconn ACL in HTTP/1.1 traffic that you need to be aware of. Particularly when using the -s flag. If a client opens more than maxconn limit number of TCP connections. Then *any* HTTP request received from that client on *any* of those connections will see a true/match for the maxconn test. So will be denied until one of the connections is closed. maxconn was designed for use in HTTP/1.0 traffic where each TCP connection carried only one HTTP request, then gets closed. So the deny action would directly result in -1 TCP connections and other requests possibly being allowed. HTTP/1.1 connections (eg Squid-3.1 and later) are by default persistent, so can carry multiple requests. The denial response does not trigger a -1 TCP connection like HTTP/.0 did. So HTTP/1.1 connections can stay open and triggering denial for a long while after the client hits the limit. Traffic where maxconn works well is becoming rare. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
