Re: [squid-users] kerberos auth failing behind a load balancer

i am using HAProxy, with Kerberos auth and have no issues. Once i
figured out the keytab bit, where you make one keytab file and put that
one keytab file on all proxies in the load balanced pool, i was off and
running. My relevant HAProxy configs:

global
        log 127.0.0.1 local1
        pidfile /var/run/haproxy.pid
        daemon

defaults
        stats enable
        stats hide-version
        stats scope .
        stats uri /admin?stats
        stats refresh 5s

listen proxy 192.168.37.1:3128
        mode http
        option http-server-close
        option forwardfor except 127.0.0.0/8
        option httpchk GET /squid-internal-periodic/store_digest HTTP/1.1
        timeout http-request 10s
        timeout queue 1m
        timeout connect 10s
        timeout client 1m
        timeout server 1m
        timeout http-keep-alive 10s
        timeout check 10s
        balance leastconn
        server proxy1 192.168.25.1:3128 check inter 10000
        server proxy2 192.168.50.1:3128 check inter 10000

in squid, i have enable the use of the x-forwarded-for and indirect
client per the below:
acl svc_chk src 192.168.25.254/32

# TAG: follow_x_forwarded_for
follow_x_forwarded_for allow svc_chk
follow_x_forwarded_for deny all

# TAG: acl_uses_indirect_client on|off
acl_uses_indirect_client on

# TAG: log_uses_indirect_client on|off
log_uses_indirect_client on

the svc_chk ACL uses the IP of the load balancer interface that is on
segment. what is nice is that the load balancer can use the proxies, as
the client IP seen is the VIP on the front-end, not the back-end IP
(which is the same IP as the on segment interface). So, with the
front-end VIP using 192.168.37.1, and having the IP of 192.168.25.254 on
the back-end, the connection comes from the 25.254 address, but the
indirect_client IP (or the first IP in the x-forwarded-for header) is
the 37.1 IP. this helps to be able to identify when the load balancer
is making a request as a client (yum update for instance), or if the
request is a service check from the HAProxy instance. i also use !
svc_chk on the access_log line to no log service check traffic. useful
to keep log volume down.

if you notice, i have two pool members, and each is on different a
network. the load balancer (which is also my router) is local to both
networks. i have to manage certain ACLs and config directives
separately given the particular proxy i am working on. the svc_chk ACL
for the other proxy has an IP of 192.168.50.254/32. The IP of the load
balancer when doing the service checks is on segment. but again, when
doing a yum update, the indirect_client IP is seen as the front-end VIP
address. i guess it helps that i point yum to the proxy VIP and not
each individual proxy.

HAProxy, with load balanced squid instances and kerberos auth is working
for me, and i am very happy with the environment. Best of luck in
yours...

-b-

On Thu, 2013-05-23 at 15:07 +0200, Sean Boran wrote:
> Chiming in here about the kemps
> I used the kemps because they were available for this project. They have
> worked quite well and as very easy to manage. HA works fine. Troubleshooting
> is OK too (its looks like a BSD box under the hood).
> L7 so that (as noted by Brett), I see to see the client IPs. Squid does some
> routing, and logging that require that.
>
> I've not tried HA proxy, or tproxy yet.
>
> Sean
>
>
> On 23 May 2013 08:11, Eliezer Croitoru <eliezer_at_ngtech.co.il> wrote:
> >
> > On 5/23/2013 8:42 AM, Brett Lymn wrote:
> >>
> >> One problem with using L2 is that you then lose the ability to log the
> >> client IP address, everything appears to come from the load balancer.
> >> Using L7 you can, at least on some load balancers, insert a
> >> X-FORWARDED-FOR header with the client IP in it so you can log this in
> >> squid using a custom log line.
> >
> > Unless you use TPROXY which is very simple to use if you understand the
> > concepts and ideas.
> > Also there is an option to use LVS or PROXY protocol in many cases.
> > I dont remeber if squid support proxy protocol stickily but L2 LB is far
> > more easy to debug and use rather then a L7 one which requires a much more
> > advanced CPU ram and other stuff.
> >
> > Eliezer
Received on Thu May 23 2013 - 21:30:44 MDT