Search squid archive

Re: Radius Accounting!

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux