On 14.11.2012 04:00, Azfar Hashmi wrote:
Hi Eliezer,
My clients simply login via browser, squid just ask them for http
auth.
Your are right squid is not a NAS hence it does not respect radius
protocols other then simple authentication request. Btw I can achieve
the multi-user login check without external_acl by using
"max_user_ip
-s 1" but this is also not working for me because I have Stunnel in
between so all requests finally forwarded to squid via stunnel
(instead
of client original ip) and squid feels all users are coming from
single
ip (stunnel ip),
Aha! now you describe what the REAL problem is.
Squid is not "feeling" the users come from the one IP address. They
*are* coming from the one IP address when they arrive at Squid for
authentication. Your description of "not working" is everybody elses
description of "working correct".
also ultimately I will have multiple squid servers so
this trick even without stunnel will not gonna work for me accurately
as
user will still be able to login from same username on different
servers.
So you have multiple users all being tunneled through some upstream TCP
proxy point (erasing the IP address information) to multiple Squid
servers which do not check each others user login state (HTTP is
stateless).
And you want to use user-IP address locking. You blame Squid for
obeying TCP and HTTP protocols?
You were nearly correct earlier when you jumped ahead (without telling
us these extra details) and said it was "impossible".
There *is* still a way around the problem. But you are going to have to
do some major network restructuring in order to achieve it.
1) remove stunnel, or, at minimum ensure each user-IP source has their
own stunnel-IP sending address (stunnel from the user machine is best
for this).
* If you need SSH encryption over a specific network path (ie Internet
between two POPs) consider using a Squid at each end of where the
stunnel is now with SSL settings on the cache_peer linkage between them.
And X-Forwarded-For feature to pass the IP addresses via HTTP header.
Either way the *shared* stunnel MUST NOT be used directly by the
clients. It is the stunnel sharing which is causing user-IP problem.
2) prevent users logging into multiple Squid.
* consider a CARP style proxy hierarchy. Where all client traffic goes
through one parent proxy which does as few actions as possible -
authentication and user-IP max limitation being among those minimums for
your case. If the traffic gets past that minimum check, passing to one
of multiple backend peers for the slower network or cache fetching.
* consider use of PAC files at the user end to enforce each user only
being given one proxy to make all their access through.
PAC files can be generated per-user by some server script as requested
by the users.
The Question is, are you willing to do that just to require each user
to only have one proxy be useful?
IMHO it is not worth the effort and you most likely have some other
reason for even considering user-IP locking which you again have not
told us about anyway. Chances are VERY high that other reason will have
a solution different to user-IP locking which can be implemented in
Squid. I will take a guess in the dark here and say "bandwidth
accounting?"
Amos
