On 7/06/19 2:38 am, Joey Officer wrote: > Greetings all, > > > > squid.conf references the ability to use the x-forwarded-for header in > ACLs by using the follow_x_forwarded_for in ACL, referenced here: > http://www.squid-cache.org/Doc/config/follow_x_forwarded_for/ and here > http://www.squid-cache.org/Doc/config/acl_uses_indirect_client/ > > > > There appear to be three pre-reqs, which I’ve met: > > > > squid.conf: acl_uses_indirect_client on > > squid built with --enable-follow-x-forwarded-for (confirmed) > > and the appropriate ACL entries (see below) > More correctly; configuration to tell Squid which clients to trust X-Forwarded-For headers from. > > > In my scenario, I have a pair of squid hosts (squid ver 3.5.6) sitting > behind a pair of haproxy/keepalived hosts which provide balancing and > redundancy/availability. Haproxy is configured to add an > x-forwarded-for header (if one doesn’t already exist) and I can see the > x-forwarded-for header in the request if I run packet capture on the > squid hosts. > > > > For this scenario, I have a box sitting on the 192.168.4.0/24 network, > which has access to three IPs on 192.168.2.0/24 network (2.30, 2.31, and > 2.32 which are haproxy1, haproxy2, and keepalived vIP respectively). > Hosts wanting internet access must using the haproxy-vip as a proxy IP, > which is then forwarded to the real squid backends. To sum up: > > > > haproxy1 – 192.168.2.30 > > haproxy2 – 192.168.2.31 > > haproxy-vip – 192.168.2.32 > > squid1 – 192.168.2.128 > > squid2 – 192.168.2.129 > > zone1 – 192.168.3.0/24 with hosts having a proxy configured as > 192.168.2.32:3128 > > client1 – 192.168.4.31 with a proxy configured as 192.168.2.32:3128 > > > > Squid will see the real-ip of the client connection as the haproxy-vip > endpoint and not the real-client IP. If I understand the documentation > correctly, I should be able to perform something like the following in > an ACL: > "client" is the initiating end of a single TCP connection. It is a relative term. The client on traffic arriving to Squid really is the haproxy-vip IP. There may be X-Forwarded-For header chains passed in by the client(s) on the other side of the HAProxy. Or other clients that bypass the HAProxy to connect directly with Squid. None of the IP's are necessarily what you consider the "real" client. Understanding that is important to understanding what follow_x_Forwarded_for does and how to use it safely. follow_x_forwarded_for tells Squid which clients it can trust to receive X-Forwarded-For values from. In other words your HAProxy machines *only* are trusted to deliver true XFF headers: acl haproxy src 192.168.2.30-192.168.2.32 follow_x_forwarded_for allow haproxy follow_x_forwarded_for deny all So whatever IPs connected to the HAProxy will be treated as Squid client-IP instead of the HAProxy themselves. Any clients bypassing the haproxy and connecting to Squid will remain being recorded properly as the "real" client. And any fake values a "real" client tries to inject will be ignored. > > # create acl source references > > acl zone1 src 192.168.3.0/24 > > acl client1 src 192.168.4.31/32 > > > > # acl to test x-forwarded-for matching header > > acl testing_proxy_dst dstdomain .google.com > > follow_x_forwarded_for allow zone1 testing_proxy_dst > > follow_x_forwarded_for allow client1 testing_proxy_dst > What you are doing here is telling Squid to trust any values / lies the zone1 or cleint1 machines send in their XFF headers - but *not* to trust the HAProxy frontends. I hope that makes it clear what is going on. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
