On 5/10/21 2:37 pm, Alex Rousskov wrote:
On 10/4/21 5:18 PM, Henning Svane wrote:
I search more on the problem and it shows that Squid as default only use IPv6
I really doubt that. Your access.log records seem to confirm my belief
that your Squid was listening on an IPv4 address (at least) -- Squid
would not see (and log) requests from IPv4 clients like 10.40.61.11 if
it were listening on IPv6 only.
Unfortunately, the exact meaning of "::" and "[::]" addresses (and even
"tcp6 ... ::" lines in netstat!) depends on the environment. Lots of
folks (mis)interpret those symbols as "any IPv6 address". That
interpretation is correct in some environments and wrong in many others.
No. "any IPv6 address" is the literal definition of "::".
The situation is that some (dual-stack, hybrid-stack) environments treat
IPv4 as a part of IPv6 and others (split-stack) do not. Squid has been
well tested in this area. It correctly opens the appropriate ports for
the stack type.
Ubuntu is dual-stack so the IPv6 port ("[::]:3128" is the correct one
to open and use for both IPv4 and IPv6 clients.
Here is one detailed answer that enumerates a few cases, including what
looks like yours (except for an sshd instead of Squid):
https://serverfault.com/a/39561
That documentation is about Windows Vista which have a split-stack where
IPv4 needs a dedicated IPv4-only port opened. As I mentioned above,
Squid is well tested for these and will properly open both IPv6 and IPv4
ports on split-stack OS.
You can, of course, verify whether Squid listens on an IPv4 address by
connecting to port 3128 on that IPv4 address using telnet or another
program.
Please note that Squid listening address has nothing to do with Squid
outgoing address. That is why I suggested that you disable
(misconfigured?) IPv6 in your environment so that Squid does not try to
forward a request it received via IPv4 using a Squid-server connection
with IPv6 addresses.
To clarify what Alex is suggesting is one of these;
Either,
Add firewall rules that block public IPv6 traffic trying to be sent
to your ISP. That means ip6tables rules to deny all traffic (not
iptables which is IPv4-only).
- this way Squid will attempt to connect to those IPv6 servers, but
when rejected should failover to IPv4 ones. If you get ISP IPv6
connectivity you just need to change firewall rules and Squid starts
working with those.
Or,
Configure the OS network interface not to allocate IPv6 addresses even
for localhost.
- this way Squid will detect the lack of IPv6 functionality on the
machine and disable all use of IPv6 - incoming, internal uses, and
outgoing traffic. If you get ISP IPv6 connectivity you need to change
both the OS interface config and then restart Squid to pickup the change
of capability.
However. Before you try those it would be helpful to test whether IPv4
is actually going to work to those servers. The issue may not be IP
related at all.
I suggest adding "dns_v4_first on" to squid.conf. Squid-4 and older will
first try connecting to IPv4 servers, only trying IPv6 ones if those
fail. You will then only see IPv6 addresses for servers which are not
available over IPv4. (Squid-5+ work differently and do not provide this
option).
One possible bug you may be encountering is a known APT issue. When APT
hands the proxy a URL with raw-IPv6 it uses the 5xx/4xx status response
as final. It does not try to reach a different IP address of the server
it was connecting to. There is nothing we can do in Squid to fix that.
Efforts to get it fixed in APT have so far not been successful.
Finally, please make sure that ICMP and ICMPv6 are functional in your
environment and do anything you can to ensure your ISP has it functional
as well. Yes there are *some* packet types that need to be blocked for
security, but the rest MUST NOT.
Squid and many other software rely on ICMP control signals indicating
that connections have failed so they can re-try using an different IP
address. This is important even for retry with two IPv4 addresses. Your
router or ISPs router should be delivering those signals to Squid,
otherwise the connection retry may not even be attempted.
Amos
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
