Hello, Alex,
The suggested workaround works correctly.
Thank you very much!
Kind regards
Ankor.
пн, 26 июн. 2023 г. в 17:11, Andrey K <ankor2023@xxxxxxxxx>:
Hello, Alex,Thank you very much!I will try the suggested workaround and share results.Kind regards,Ankor.пн, 26 июн. 2023 г. в 16:49, Alex Rousskov <rousskov@xxxxxxxxxxxxxxxxxxxxxxx>: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
