On 20/10/2011 18:11, E.S. Rosenberg wrote:
> On the whole I just need the backend to know the username, or what
> 'browsing plan' the session is using, sometimes plans are also
> determined based on src IP (ie. certain stations aren't allowed to
> browse no matter who's logged in, or are supposed to only have access
> to a whitelist even when staff are using them), so I think a
> 'NAT'-like method is most likely what i need.
Just to highlight a feature that not everyone yet knows about, but in
the 3.2 series there is support for conntrack marking both to copy the
original connection mark to the output and also to mark connections
based on various squid criteria. Conntrack marks don't affect anything
outside of the network stack they are running on (ie next hop knows
nothing), but they can be used to help integrate a firewall to achieve
various clever effects.
I'm not sure that they help you that much, so this was more to add an
idea on the off chance it helps... At a pinch you can use your firewall
to change IP address or TOS marks to communicate conntrack marks outside
of the box, but it's a bit crude...
The other thing is that I believe you can use the auth helpers to set
the upstream auth username to be somewhat different to the logged in
user? So I *believe* you can achieve the effect that you can do some
database lookup on users in group X to get a group name "X" and pass
that "X" upstream as the auth user. The point is that you don't need to
use IP as your upstream signaling criteria, you can use the auth user,
but pre-grouped to the service class names that you need. As an
extension to this basic idea I believe you can use the auth helpers to
derive these "usernames" from other criteria such as client IP address,
etc. Does this help?
Good luck
Ed W
Received on Thu Oct 20 2011 - 18:31:43 MDT
This archive was generated by hypermail 2.2.0 : Fri Oct 21 2011 - 12:00:03 MDT