Re: [squid-users] something better than using IP address?

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_at_treenet.co.nz> 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_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.STABLE7
>>

-- 
Please use Squid 2.7.STABLE3 or 3.0.STABLE7