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)
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
