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@xxxxxxxxxxxx> 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
