Re: [squid-users] acl bug (when peers configured)
Henrik Nordstrom disse na ultima mensagem: > On tor, 2007-08-30 at 08:27 -0300, Michel Santos wrote: > >> *THIS* is the thing here: that any acl configured on the frontend cache >> is >> not beeing applied to any request from the peer > > Then check your http_access rules. You have something else in there... > > There is absolutely nothing special about peers in access controls. They > are just HTTP clients just as any other HTTP client. > ok, then I will isolate a pair from the cluster at night and doublecheck everything thank's so far michel ... Datacenter Matik http://datacenter.matik.com.br E-Mail e Data Hosting Service para Profissionais.
Re: [squid-users] acl bug (when peers configured)
On tor, 2007-08-30 at 08:27 -0300, Michel Santos wrote: > *THIS* is the thing here: that any acl configured on the frontend cache is > not beeing applied to any request from the peer Then check your http_access rules. You have something else in there... There is absolutely nothing special about peers in access controls. They are just HTTP clients just as any other HTTP client. Regards Henrik signature.asc Description: This is a digitally signed message part
Re: [squid-users] acl bug (when peers configured)
Henrik Nordstrom disse na ultima mensagem: > On tor, 2007-08-30 at 06:02 -0300, Michel Santos wrote: >> There is appearently an acl bug >> >> acls do not work for peers > > They do work for peers, just the same as any other http client. There is > nothing special about peers in the access controls. > >> acl all src 200.152.80.0/20 > > Warning: Don't redefine the "all" acl unless you are very careful. It's > used in a number of defaults and meant to match "the whole world", and > results can become a bit confusing if redefined... > > Instead define a "mynetwork" acl to match your clients.. > I just did this but does not change the misbehaviour I described >> acl danger urlpath_regex -i instal\.html >> http_access deny all danger >> # >> >> so far this works for "all", I mean it blocks as wanted >> >> >> # >> acl all src 200.152.80.0/20 >> acl peer src 200.152.83.40 >> acl danger urlpath_regex -i instal\.html >> http_access deny all danger >> http_access deny peer danger > > Nothing obviously wrong, apart from the use of the "all" acl.. ok, in fact the acl all ... is not the point and works anyway despite your observation, what is NOT working as supposed is acl peer ... and it's following deny clause for the peer > >> does NOT when accessing directly from a browser from 200.152.83.40 > > Should it? When going directly Squid is not used... well well ... directly from a browser not as "always_direct" or something I mean here when acessing the parent as client ok, since the frontend cache is a transparent proxy it catch/intercept this connection and should apply the acl what it in fact does so long as the IP does not part of "acl peer src" when I change the "acl peer src *IP*" then the acl works for this machine as well as for all not_peer_clientes of the frontend cache *THIS* is the thing here: that any acl configured on the frontend cache is not beeing applied to any request from the peer michel ... Datacenter Matik http://datacenter.matik.com.br E-Mail e Data Hosting Service para Profissionais.
Re: [squid-users] acl bug (when peers configured)
On tor, 2007-08-30 at 06:02 -0300, Michel Santos wrote: > There is appearently an acl bug > > acls do not work for peers They do work for peers, just the same as any other http client. There is nothing special about peers in the access controls. > acl all src 200.152.80.0/20 Warning: Don't redefine the "all" acl unless you are very careful. It's used in a number of defaults and meant to match "the whole world", and results can become a bit confusing if redefined... Instead define a "mynetwork" acl to match your clients.. > acl danger urlpath_regex -i instal\.html > http_access deny all danger > # > > so far this works for "all", I mean it blocks as wanted > > > # > acl all src 200.152.80.0/20 > acl peer src 200.152.83.40 > acl danger urlpath_regex -i instal\.html > http_access deny all danger > http_access deny peer danger Nothing obviously wrong, apart from the use of the "all" acl.. > does NOT when accessing directly from a browser from 200.152.83.40 Should it? When going directly Squid is not used... > and does NOT work when configuring localhost as proxy on 200.152.83.40 What do access.log say on both proxies? Regards Henrik signature.asc Description: This is a digitally signed message part
[squid-users] acl bug (when peers configured)
There is appearently an acl bug acls do not work for peers # acl all src 200.152.80.0/20 acl danger urlpath_regex -i instal\.html http_access deny all danger # so far this works for "all", I mean it blocks as wanted # acl all src 200.152.80.0/20 acl peer src 200.152.83.40 acl danger urlpath_regex -i instal\.html http_access deny all danger http_access deny peer danger # does NOT when accessing directly from a browser from 200.152.83.40 and does NOT work when configuring localhost as proxy on 200.152.83.40 does only block when I configure the acl on 200.152.83.40's squid same for dstdomain and other acl attributes that is not a feature but a bug am I right? michel ... Datacenter Matik http://datacenter.matik.com.br E-Mail e Data Hosting Service para Profissionais.
