On 31/10/2023 13:08, Stephen Borrill wrote:
On 18th April 2023 Alex Rousskov wrote:
On 4/18/23 03:38, Ralf Hildebrandt wrote:
We're using squid-6, currently v4 only. The use case for us is mostly
our users using our proxy to retrieve full text publications of
several thousand medical journals... via IPv4.
The publishers "know" our IPv4 range for the proxies and allow us to
download freely. What they don't (yet) know is our ipv6 range.
Thus arises the need to "fall back" to ipv4 in the unlikely case some
publisher already has ipv6, we connect via ipv6 and suddenly are not
allowed to download the publications.
Is there an acl for that kind of need?
I will rephrase your question to avoid the distraction of "acl":
How can I configure Squid to try IPv4 if IPv6 fails?
The answer depends on how IPv6 fails:
1. If IPv6 fails at DNS resolution time (i.e. the DNS resolver does not respond with a usable address to a AAAA query), then Squid will automatically use IPv4 (i.e. the DNS resolver address in an A response). There is nothing to configure.
2. If IPv6 fails at TCP connection establishment time, then Squid will automatically use an IPv4 connection. There is nothing to configure (although there are a few Happy Eyeballs configuration options that you can tune).
3. If IPv6 fails at TLS connection establishment time, then, IIRC, #2 applies unless SslBump is involved. Squid will not retry failed TLS connections that are subject to SslBump IIRC.
4. If IPv6 fails at HTTP request time, then Squid will retry in _some_ cases. See [1] for a long list of conditions; you are probably mostly interested in the last four or five bullets, but keep in mind that the list is of cases where Squid does _not_ re-forward the failed request.
[1] https://wiki.squid-cache.org/SquidFaq/InnerWorkings#when-does-squid-re-forward-a-client-request
You can also replace your DNS resolver with a custom one (that drops AAAA answers) or, as Adam has suggested, with hard-coded IPv4-only /etc/hosts entries.
On a machine with no IPv6 connection to the Internet and bearing in mind 2 and 3 above,
what is going on in the following situation? The host is being resolved to IPv6,
the connection is failing with (presumably) no route to host and the client's connection is rejected
with a 503 error:
peer_select.cc(373) checkAlwaysDirectDone: ALLOWED
peer_select.cc(379) checkAlwaysDirectDone: direct = DIRECT_YES (always_direct allow)
peer_select.cc(612) selectMore: CONNECT forcesafesearch.google.com
peer_select.cc(1102) addSelection: adding HIER_DIRECT#forcesafesearch.google.com
peer_select.cc(460) resolveSelected: Find IP destination for: forcesafesearch.google.com:443' via forcesafesearch.google.com
Address.cc(389) lookupHostIP: Given Non-IP 'forcesafesearch.google.com': hostname or servname not provided or not known
peer_select.cc(1174) handlePath: PeerSelector33640 found conn271011 local=[::] remote=[2001:4860:4802:32::78]:443 HIER_DIRECT flags=1, destination #1 for forcesafesearch.google.com:443
peer_select.cc(1180) handlePath: always_direct = ALLOWED
peer_select.cc(1181) handlePath: never_direct = DENIED
peer_select.cc(1182) handlePath: timedout = 0
peer_select.cc(479) resolveSelected: PeerSelector33640 found all 1 destinations for forcesafesearch.google.com:443
peer_select.cc(480) resolveSelected: always_direct = ALLOWED
peer_select.cc(481) resolveSelected: never_direct = DENIED
peer_select.cc(482) resolveSelected: timedout = 0
client_side.cc(1953) clientParseRequests: Not parsing new requests, as this request may need the connection
FwdState.cc(1568) GetMarkingsToServer: from [::] tos 0 netfilter mark 0
ConnOpener.cc(42) ConnOpener: will connect to conn271013 local=[::] remote=[2001:4860:4802:32::78]:443 HIER_DIRECT flags=1 with 60 timeout
comm.cc(372) comm_openex: comm_openex: Attempt open socket for: [::]
comm.cc(414) comm_openex: comm_openex: Opened socket conn271014 local=[::] remote=[::] FD 1218 flags=1 : family=24, type=1, protocol=6
fd.cc(168) fd_open: fd_open() FD 1218 forcesafesearch.google.com
ConnOpener.cc(312) createFd: conn271013 local=[::] remote=[2001:4860:4802:32::78]:443 HIER_DIRECT flags=1 will timeout in 60
comm.cc(844) _comm_close: start closing FD 1218 by ConnOpener.cc:232
comm.cc(580) commUnsetFdTimeout: Remove timeout for FD 1218
HappyConnOpener.cc(522) sendFailure: conn271013 local=[::] remote=[2001:4860:4802:32::78]:443 HIER_DIRECT flags=1 @0
fd.cc(93) fd_close: fd_close FD 1218 forcesafesearch.google.com
tunnel.cc(1364) sendError: aborting transaction for HappyConnOpener gave up
errorpage.cc(751) errorSend: conn271010 local=127.0.0.1:8123 remote=127.0.0.1:56146 FD 1217 flags=1, err=ERR_CONNECT_FAIL
After restarting (not reloading), I get the following and it will work for while before stopping again:
peer_select.cc(1174) handlePath: PeerSelector1666 found conn12948 local=0.0.0.0 remote=216.239.38.120:443 HIER_DIRECT flags=1, destination #1 for forcesafesearch.google.com:443
peer_select.cc(1180) handlePath: always_direct = ALLOWED
peer_select.cc(1181) handlePath: never_direct = DENIED
peer_select.cc(1182) handlePath: timedout = 0
peer_select.cc(1174) handlePath: PeerSelector1666 found conn12949 local=[::] remote=[2001:4860:4802:32::78]:443 HIER_DIRECT flags=1, destination #2 for forcesafesearch.google.com:443
peer_select.cc(1180) handlePath: always_direct = ALLOWED
peer_select.cc(1181) handlePath: never_direct = DENIED
peer_select.cc(1182) handlePath: timedout = 0
peer_select.cc(479) resolveSelected: PeerSelector1666 found all 2 destinations for forcesafesearch.google.com:443
This is a newly occurring problem after upgrade from 4.x to 6.3.
--
Stephen
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.squid-cache.org/listinfo/squid-users
