On 7/17/23 08:28, Scott wrote:
On 7/16/23 08:03, Scott wrote:
Hi all,
I have four IPv4s that I use for outgoing source addresses to origin servers.
I currently have them used randomly, but this sometimes causes issues for
certain sites that get confused if your source changes for various resources.
For these sites I have an exception to the random IPs.
I decided to create the following acls which should match on the 2 low-order
bits in the client addresses:
acl tm_src_v4_00 src 10.0.0.0 255.0.0.3
The above adds two IP addresses to the tm_src_v4_00 ACL: 10.0.0.0 and
255.0.0.3.
Try this (untested but matching the documented syntax) instead:
acl tm_src_v4_00 src 10.0.0.0/255.0.0.3
Unfortunately your suggestion didn't work: all clients ended up with same
outgoing IP.
Noted. I was only focusing on the wrong syntax. I did not check any
other details and did not mean to imply that the above sketch should work.
The warning in the logs gives the reason:
2023/07/17 22:19:28| WARNING: Netmasks are deprecated. Please use CIDR masks instead.
2023/07/17 22:19:28| WARNING: IPv4 netmasks are particularly nasty when used to compare IPv6 to IPv4 ranges.
2023/07/17 22:19:28| WARNING: For now we will assume you meant to write /8
2023/07/17 22:19:28| aclIpParseIpData: WARNING: Netmask masks away part of the specified IP in '10.0.0.3/255.0.0.3'
It's treating the mask as a /8.
So back to my problem statement - is there any way to use all four outgoing
IPs (v4 and v6) with the clients tied to a consistent address?
If you cannot use CIDR masks suggested by the WARNING above (again, I
have not checked any details, including whether they can be used for
your use case), then you can (at, say, http_access time) use an external
ACL that implements whatever mapping algorithm you want and annotates
the transaction accordingly, so that you can check that annotation using
"note" ACL at tcp_outgoing_address time.
There are relevant examples in the email thread referenced below (which
uses "cache_peer_access" instead of your "tcp_outgoing_address", but
those directives are similar as far as your use case is concerned).
http://lists.squid-cache.org/pipermail/squid-users/2023-April/025783.html
HTH,
Alex.
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
