On 6/23/23 08:05, Andrey K wrote:
A link to the uploaded ALL,9 log is: ...
Your Squid is suffering from a bug in its ICAP client implementation:
AFAICT, all ICAP transactions will trigger these WARNINGS if
tcp_outgoing_address rules (the ones these ICAP transactions can reach)
use a request-dependent ACL (e.g., dstdomain).
I filed bug #5280 at https://bugs.squid-cache.org/show_bug.cgi?id=5280
The workaround suggested in my previous response should avoid these
WARNINGS for the affected ICAP transactions. However, it will also
effectively disable these WARNINGS for other transactions without
requests (if any). There may be a way to be more selective, but I cannot
suggest something specific right now. FWIW, the "transaction_initiator"
ACL cannot help here because it needs access to the request as well.
HTH,
Alex.
I think we could ignore these warnings as squid works perfectly
> I do not think we have enough information to reach that "works
> perfectly" conclusion. At the very least, you should test with a domain
> that should match domdst_SIProxy rather than one that should not match
> (and does not match, but for the wrong reason).
This is a production system and it works as expected: for domains from
the domdst_SIProxy ACL it uses correct tcp_outgoing_address: 10.72.235.184
> If you do not want to know what is actually going on (e.g., whether
> there is a Squid bug or misconfiguration here), then you can use a "has"
> ACL to protect your domdst_SIProxy ACL in tcp_outgoing_address context
> from request-free evaluations. Here is an untested sketch:
>
> acl hasRequest has request
>
> # If Squid has no request access (possibly due to Squid bugs),
> # then do not use 10.72.235.184, even if domdst_SIProxy would
> # have matched if Squid had access to the request.
> tcp_outgoing_address 10.72.235.184 hasRequest domdst_SIProxy
Thank you, Alex, I will try this workaround after you have time to take
a look at ALL,9 log.
Kind regards,
Ankor.
чт, 22 июн. 2023 г. в 20:11, Alex Rousskov
<rousskov@xxxxxxxxxxxxxxxxxxxxxxx
<mailto:rousskov@xxxxxxxxxxxxxxxxxxxxxxx>>:
On 6/22/23 04:59, Andrey K wrote:
> I reproduced the issue in the test environment.
> I configured my squid with the debug_options: ALL,1 28,9
> and ran the test curl from the same proxy host:
> curl -m 4 -k --tlsv1.2 --proxy-user 'user:pass' -s -o
/dev/null -w
> "%{http_code}" --proxy localhost:3131 https://archive.org
<https://archive.org>
> <https://archive.org <https://archive.org>>
>
> The client got the 200-response and it works fine.
>
> In the access.log the corresponding records are:
> 2023-06-22 10:59:58| 747 127.0.0.1 NONE_NONE/200/- 0 CONNECT
> archive.org:443 <http://archive.org:443> <http://archive.org:443
<http://archive.org:443>> - HIER_DIRECT/archive.org
<http://archive.org>
> <http://archive.org <http://archive.org>> - - - -
> 2023-06-22 10:59:58| 201 127.0.0.1 TCP_MISS/200/200 3833 GET
> https://archive.org/ <https://archive.org/> <https://archive.org/
<https://archive.org/>> - HIER_DIRECT/archive.org <http://archive.org>
> <http://archive.org <http://archive.org>> text/html - - -
>
> The cache.log is available at the link:
>
https://drive.google.com/file/d/12xQch5nHAzijAh4PxZV4mZzjviYX7l7B/view?usp=sharing <https://drive.google.com/file/d/12xQch5nHAzijAh4PxZV4mZzjviYX7l7B/view?usp=sharing>
> There are three warnings there:
> grep WARN /tmp/acl.log
> 2023/06/22 10:59:57.875 kid6| WARNING: domdst_SIProxy ACL is
used in
> context without an HTTP request. Assuming mismatch.
> 2023/06/22 10:59:57.884 kid6| WARNING: domdst_SIProxy ACL is
used in
> context without an HTTP request. Assuming mismatch.
> 2023/06/22 10:59:58.536 kid6| WARNING: domdst_SIProxy ACL is
used in
> context without an HTTP request. Assuming mismatch.
The shared log is not detailed enough for me to pinpoint the problem,
but there are several places in Squid code where
tcp_outgoing_address is
used without a request. Some of those places look like Squid bugs to
me.
Some look legitimate. Again, I cannot tell whether your Squid is
hitting
one of those places; if you want more definitive answers, please
share a
compressed ALL,9 log while reproducing the problem with that curl
transaction:
https://wiki.squid-cache.org/SquidFaq/BugReporting#debugging-a-single-transaction <https://wiki.squid-cache.org/SquidFaq/BugReporting#debugging-a-single-transaction>
> The domdst_SIProxy ACL is used only to change the outgoing
address for
> specific domains
> The test URL https://archive.org <https://archive.org> is not in
the domdst_SIProxy list.
That fact does not matter -- the warnings are printed (and the
directive
is ignored) _before_ Squid checks the configured/listed values.
> I think we could ignore these warnings as squid works perfectly
I do not think we have enough information to reach that "works
perfectly" conclusion. At the very least, you should test with a domain
that should match domdst_SIProxy rather than one that should not match
(and does not match, but for the wrong reason).
> maybe there is a workaround to suppress logs flooding?
If you do not want to know what is actually going on (e.g., whether
there is a Squid bug or misconfiguration here), then you can use a
"has"
ACL to protect your domdst_SIProxy ACL in tcp_outgoing_address context
from request-free evaluations. Here is an untested sketch:
acl hasRequest has request
# If Squid has no request access (possibly due to Squid bugs),
# then do not use 10.72.235.184, even if domdst_SIProxy would
# have matched if Squid had access to the request.
tcp_outgoing_address 10.72.235.184 hasRequest domdst_SIProxy
Otherwise, consider sharing an ALL,9 log as discussed above.
HTH,
Alex.
> пн, 12 июн. 2023 г. в 10:54, <ngtech1ltd@xxxxxxxxx
<mailto:ngtech1ltd@xxxxxxxxx>
> <mailto:ngtech1ltd@xxxxxxxxx <mailto:ngtech1ltd@xxxxxxxxx>>>:
>
> Hey Ankor,
>
> There is some missing context so I would be able to reproduce
this
> issue.
> Is this some kind of CONNECT request?
>
> If you can describe in more technical details the setup and what
> client are you using,
> Maybe couple sanitized log lines it would help to understand
better
> the scenario.
>
> Eliezer
>
> From: squid-users <squid-users-bounces@xxxxxxxxxxxxxxxxxxxxx
<mailto:squid-users-bounces@xxxxxxxxxxxxxxxxxxxxx>
> <mailto:squid-users-bounces@xxxxxxxxxxxxxxxxxxxxx
<mailto:squid-users-bounces@xxxxxxxxxxxxxxxxxxxxx>>> On Behalf Of
> Andrey K
> Sent: Friday, June 9, 2023 10:03
> To: Squid Users <squid-users@xxxxxxxxxxxxxxxxxxxxx
<mailto:squid-users@xxxxxxxxxxxxxxxxxxxxx>
> <mailto:squid-users@xxxxxxxxxxxxxxxxxxxxx
<mailto:squid-users@xxxxxxxxxxxxxxxxxxxxx>>>; Amos Jeffries
> <squid3@xxxxxxxxxxxxx <mailto:squid3@xxxxxxxxxxxxx>
<mailto:squid3@xxxxxxxxxxxxx <mailto:squid3@xxxxxxxxxxxxx>>>
> Subject: Using tcp_outgoing_address with ACL
>
> Hello,
>
> We use the tcp_outgoing_address feature to access some hosts
using a
> dedicated source IP address.
>
> acl domdst_SIProxy dstdomain
> "/data/squid.user/etc/squid/categories/domdst_SIProxy"
> tcp_outgoing_address 10.72.235.129 domdst_SIProxy
>
> It works fine, but logs are flooded with warnings like this:
> 2023/06/09 08:30:07 kid2| WARNING: domdst_SIProxy ACL is
used in
> context without an HTTP request. Assuming mismatch.
>
> I found a similar case:
>
http://lists.squid-cache.org/pipermail/squid-users/2015-January/001629.html <http://lists.squid-cache.org/pipermail/squid-users/2015-January/001629.html> <http://lists.squid-cache.org/pipermail/squid-users/2015-January/001629.html <http://lists.squid-cache.org/pipermail/squid-users/2015-January/001629.html>> where Amos suggested using a patch as a solution.
> We have Squid Version 5.5. Is there a similar patch for our
version,
> or can we just ignore these messages?
>
> Kind regards,
> Ankor.
>
> _______________________________________________
> squid-users mailing list
> squid-users@xxxxxxxxxxxxxxxxxxxxx
<mailto:squid-users@xxxxxxxxxxxxxxxxxxxxx>
> <mailto:squid-users@xxxxxxxxxxxxxxxxxxxxx
<mailto:squid-users@xxxxxxxxxxxxxxxxxxxxx>>
> http://lists.squid-cache.org/listinfo/squid-users
<http://lists.squid-cache.org/listinfo/squid-users>
> <http://lists.squid-cache.org/listinfo/squid-users
<http://lists.squid-cache.org/listinfo/squid-users>>
>
>
> _______________________________________________
> squid-users mailing list
> squid-users@xxxxxxxxxxxxxxxxxxxxx
<mailto:squid-users@xxxxxxxxxxxxxxxxxxxxx>
> http://lists.squid-cache.org/listinfo/squid-users
<http://lists.squid-cache.org/listinfo/squid-users>
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
<mailto:squid-users@xxxxxxxxxxxxxxxxxxxxx>
http://lists.squid-cache.org/listinfo/squid-users
<http://lists.squid-cache.org/listinfo/squid-users>
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
