[squid-users] Problem with 6.1 squidclient mgr:

Wed Aug 2 14:16:06 UTC 2023

On 7/31/23 09:47, Alex Rousskov wrote:
> On 7/31/23 06:13, Gérard Parat wrote:
> 
>> I use Squid as a Windows 10 service with Cygwin since 5.7 release.
>>
>> I usually monitor activity with squidclient mgr: but since 6.1 it
>> doesn't work anymore:
>>
>>    * HTTP/1.1 403 Forbidden
>>
>> However, squidclient cache_object://localhost/ is working fine.
>>
>> Is there new options to add to squid.conf to access mgr: ?
> 
> Does your Squid identify itself as "localhost" in Via headers and other 
> output? If not, you are probably suffering from bug #5283:
> https://bugs.squid-cache.org/show_bug.cgi?id=5283
> 
> There are several workarounds, including Squid patches, but no long-term 
> solution yet. If you do not want to patch Squid, use "squidclient -h..." 
> as suggested at https://bugs.squid-cache.org/show_bug.cgi?id=5283#c1

Just an update in case somebody else suffers from this problem and reads 
this thread: After looking through Gérard's debugging logs, I can 
confirm that this setup suffers from Squid bug #5283, and that 
"squidclient -h" workaround helps. However, that workaround is not 
sufficient in this particular use case because

1. Like many Squids, this Squid is configured to allow manager requests 
sent from localhost only. When "squidclient -h example.text mgr:info" 
runs on the same host as Squid, and example.test resolves to something 
other than a localhost address (e.g., 192.168.28.150), squidclient 
connects from that other IP address, and Squid denies that request 
because the manager ACL matches but the localhost ACL does not.

2. On Linux, the problem in item 1 above can be overcome by telling 
squidclient (that runs on the same host as Squid) to connect from 
127.0.0.1 or another localhost address. For example:

     squidclient -v -l 127.0.0.1 -h example.text mgr:info

However, in some environments (e.g., Windows 10?), it is not possible to 
connect from 127.0.0.1 to, say, 192.168.28.150, even if both IPs belong 
to the same host where squidclient is executed. In those environments, 
forcing source address results in a squidclient TCP connection 
establishment failure:

     $ squidclient -v -l 127.0.0.1 -h example.text mgr:info
     ...
     Transport detected: IPv4-mapped  and IPv6
     Resolving 127.0.0.1 ...
     Resolving... example.test
     Connecting... example.test (192.168.28.150:3128)
     ERROR: Cannot connect to 192.168.28.150:3128

Some client have "resolve DNS name X as IP address Y" features (e.g., 
"curl --resolve") that can be used to work around item 2 problems, but 
squidclient lacks those.

HTH,

Alex.

--- cache.log analysis ---

All three cases below were handled as I would expect them to be handled 
given the current set of known Squid problems. SelfName or 
"example.test" is the host name that this Squid identifies itself as *in 
cache manager request handling context*. In general, SelfName may be 
different from the name used in Via and Cache-Status headers, 
complicating the issues further. In this setup, they are the same.

## Case A: Request not matching SelfName of the receiving Squid

     $ squidclient mgr:info

     ... HTTP Client local=[::1]:3128 remote=[::1]
     GET http://localhost:3128/squid-internal-mgr/info HTTP/1.0
     Host: localhost:3128
     User-Agent: squidclient/6.1

The above squidclient request is not recognized as a request to the 
cache manager of the receiving Squid because receiving Squid's SelfName 
is example.test rather than localhost. Squid bug #5283 is relevant here.

Receiving Squid (let's call it Squid A) forwards the above request to 
the server at localhost:3128 address (let's call that Squid B). In this 
test, Squid A and Squid B are the same Squid instance, but Squid 
forwarding code does not know that. Forwarding a request from Squid A 
instance to (the same) Squid B instance creates a forwarding loop:

     2023/08/01 11:14:15| WARNING: Forwarding loop detected for:
     GET /squid-internal-mgr/info HTTP/1.1
     Host: example.test:3128
     User-Agent: squidclient/6.1
     Via: 1.0 example.test (squid/6.1)

Squid B denies the request because Squid B has detected the above 
forwarding loop and all forwarding loops are blocked:

     HTTP/1.1 403 Forbidden
     Server: squid/6.1
     X-Squid-Error: ERR_ACCESS_DENIED 0
     Cache-Status: example.test;detail=mismatch
     Via: 1.1 example.test (squid/6.1)

Squid A forwards the above denial response to squidclient (note the two 
Cache-Status fields and two Via field values):

     HTTP/1.1 403 Forbidden
     Server: squid/6.1
     X-Squid-Error: ERR_ACCESS_DENIED 0
     Cache-Status: example.test;detail=mismatch
     Via: 1.1 example.test (squid/6.1),
          1.1 example.test (squid/6.1)
     Cache-Status: example.test;detail=no-cache

## Case B: Not-from-localhost request

     $ squidclient -h example.test mgr:info

     ... HTTP Client local=192.168.28.150:3128 remote=192.168.28.150
     GET http://example.test:3128/squid-internal-mgr/info HTTP/1.0
     Host: example.test:3128
     User-Agent: squidclient/6.1

The above squidclient request is recognized as a request to the cache 
manager of the receiving Squid and denied because access is from 
192.168.28.150 rather than localhost.

     HTTP/1.1 403 Forbidden
     X-Squid-Error: ERR_ACCESS_DENIED 0
     Cache-Status: example.test
     Via: 1.1 example.test (squid/6.1)

## Case C: Request using a relative URL

     $ curl http://localhost:3128/squid-internal-mgr/info

     ... HTTP Client local=127.0.0.1:3128 remote=127.0.0.1
     GET /squid-internal-mgr/info HTTP/1.1
     Host: localhost:3128
     User-Agent: Mozilla/5.0...

The above browser request was recognized as a request to the cache 
manager of the receiving Squid because the receiving Squid ignores the 
Host header when receiving a relative URL and creates an absolute URL 
with its own SelfName:

     checking 'http://example.test:3128/squid-internal-mgr/info'

This is a known Squid bug already marked in Squid sources. If that bug 
is fixed (without any other fixes), the above to-localhost request would 
be denied as well.

That refactored URL matches SelfName, of course. The request came from a 
localhost-matching address. It is allowed/processed:

     HTTP/1.1 200 OK
     Server: squid/6.1
     Cache-Status: example.test;detail=mismatch
     Via: 1.1 example.test (squid/6.1)