Jian Wang wrote:
Thanks Amos, that's helpful.
Or, if the essence of your system is a splash-screen type interface (first
view is yoru page, second is what the client asks for) you could try a
cone-off deny splash using the same ACL and:
Yes, you are right. Actually, we did considered external_acl at the
begining. But we were worring about the performance since we were
aiming at a network with thousands of clients. The redirecors can be
multithreaded, we thought it would give better performance--and
indeed, in our experiment, the average redirector time is good enough
to our goal. It's not untill recently did we realized that External
ACL can also be multithreaded by set concurrency=n. Although we didn't
try ACL method, I think it may worth a trying to compare with our
method. And, as you suggested, ACL has all access to HTTP headers, I'm
even more interested in trying ACL method. Thanks for your suggestion.
Aha, there is another benefit of external ACL. The results may be cached
on the input pattern. Redirector needs be called for every requested URL.
My understanding from your earlier post was that you had a splash-screen
redirection all working, but wanted to identify individual clients behind
the NAT/PAT?
Yes, exactly. I'm seeking a way to "identify individual clients behind
the NAT/PAT".
Squid ACL have access to all the HTTP headers. The NAT/PAT destroys all
reliable information, but you may still be able to selectively look for
special headers only sent on followups to you app requests. Cookies or
Referer, etc
That's a delightful information to me. We considered Cookies, but for
some reason, we really don't want to use it--if it's not the only
choice. Beside this, are you saying that it's possible to use "NAT/PAT
router ip" + "some other header info" to identify a client? I will try
to look into HTTPHeader doc. It would be highly appreciated if anyone
has more suggestions on this.
It needs to be some header which you can get the client to send for
followup requests, but not normally sent. A session cookie is often good
for this.
I'm assuming that you want to do some local processing (database records
etc) with external_acl_type. But if not, the plain old req_header ACL
should do as well for a splash.
http://www.squid-cache.org/Versions/v2/2.7/cfgman/acl.html
acl aclname req_header header-name [-i] any\.regex\.here
# regex match against any of the known request headers. May be
# thought of as a superset of "browser", "referer" and "mime-type"
# ACLs.
For example, PAT use
different port to assign an IP address, this info should be included
in the packets send to Squid; the question is how can we retrieve
this info?
Redirectors and Reverse Proxies cannot do that. To recover NAT information
you need an Intercepting Proxy and administrative control of the NAT
gateways.
Actually, we are doing an Intercepting Proxy. Now I believe abandon
redirectors and turn to ACL is a good idea. In addition, suppose we
can talk to administrator of the NAT/PAT gateway, what kind of
information I should ask for to make my ACL work as expected?
They need to route all port-80 traffic to the squid box for NAT/PAT on
the same box as an intercepting Squid. Not usually doable if they are a
remote or upstream site.
Thanks a lot.
My best regards,
Jian
On Sat, Jul 12, 2008 at 11:01 PM, Amos Jeffries <squid3@xxxxxxxxxxxxx> wrote:
Jian Wang wrote:
Hi, Amos,
First, thanks for the reply.
Try ACL, up to and including custom external_acl_type. They can check
based
on just about anything you like and permit/deny redirection via
url_rewrite_access.
Could you please give me more details(or direct me to some docs) about
this?
http://www.squid-cache.org/Versions/v2/2.7/cfgman/external_acl_type.html
http://www.squid-cache.org/Versions/v2/2.7/cfgman/url_rewrite_access.html
Or, if the essence of your system is a splash-screen type interface (first
view is yoru page, second is what the client asks for) you could try a
cone-off deny splash using the same ACL and:
http://www.squid-cache.org/Versions/v2/2.7/cfgman/deny_info.html
And in our application, we allow everyone in the subnet to access the
Squid (e.g., a temporary visitor with no user account and is from a
PATed subnet). Therefore, it seems to me that we do not have to
configure much about the ACL--as long as Squid allow the ip address of
the NATed/PATed router ip.
The presence of NAT destroys almost all easily retrieved useful information
about the actual client.
PAT often goes even further in destroying *all* transport layer information
about the client.
My understanding from your earlier post was that you had a splash-screen
redirection all working, but wanted to identify individual clients behind
the NAT/PAT?
Our goal is to distinguish different client computers, even they are
from different PAT/NAT subnet. Intuitively, MAC address can do this.
However, MAC is the datalink layer protocol. I think it won't work for
the PAT/NAT.
No, MAC/ARP is link-local. And wont work for any machine other side of a
router.
So I'm seeking a solution that can uniquely identify a
client computer--despite of different subnet. Is it possible to find
such information from somewhere in Squid?
Squid ACL have access to all the HTTP headers. The NAT/PAT destroys all
reliable information, but you may still be able to selectively look for
special headers only sent on followups to you app requests. Cookies or
Referer, etc
For example, PAT use
different port to assign an IP address, this info should be included
in the packets send to Squid; the question is how can we retrieve
this info?
Redirectors and Reverse Proxies cannot do that. To recover NAT information
you need an Intercepting Proxy and administrative control of the NAT
gateways.
http://wiki.squid-cache.org/ConfigExamples
http://wiki.squid-cache.org/ConfigExamples/LinuxInterceptDNAT
http://wiki.squid-cache.org/ConfigExamples/NatAndWccp2
Thanks a lot.
Jian
On Sat, Jul 12, 2008 at 6:59 AM, Amos Jeffries <squid3@xxxxxxxxxxxxx>
wrote:
Jian Wang wrote:
Hi, all,
Recently, we used Squid redirectors to solve an application problem.
Better to fix the application problem than to hack around it with
complication.
Our redirectors are checking incoming requests against a database
table to see if this IP has already accessed Squid--redirect only if
ip is not in database.
We now have the concern that it may cause problem when applying our
application to a NATed or PATed network. In those networks, private IP
addresses are not seen from the upper level router(on where our Squid
is sitting). Therefore, it seems to be not possible for us make our
redirectors work as expected.
In our application, we don't want to use any user name + password for
access authentication, our situation is that everyone is authorized.
In the Squid redirector input string, we can only get IP address(plus
FQDN at most, which doesn't help at all). Is there a way for Squid to
solve this problem?
Try ACL, up to and including custom external_acl_type. They can check
based
on just about anything you like and permit/deny redirection via
url_rewrite_access.
Amos
--
Please use Squid 2.7.STABLE3 or 3.0.STABLE7
--
Please use Squid 2.7.STABLE3 or 3.0.STABLE7
--
Please use Squid 2.7.STABLE3 or 3.0.STABLE7
