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_at_treenet.co.nz> 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.STABLE7Received on Sun Jul 13 2008 - 04:01:30 MDT
This archive was generated by hypermail 2.2.0 : Sun Jul 13 2008 - 12:00:04 MDT