Hello, Alex,
Thank you very much!
I will try the suggested workaround and share results.
Kind regards,
Ankor.
пн, 26 июн. 2023 г. в 16:49, Alex Rousskov <rouss...@measurement-factory.com
>:
> 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
> > <rouss...@measurement-factory.com
> > <mailto:rouss...@measurement-factory.com>>:
> >
> > 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, <ngtech1...@gmail.com
> > <mailto:ngtech1...@gmail.com>
> > > <mailto:ngtech1...@gmail.com <mailto:ngtech1...@gmail.com>>>:
> > >
> > > 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-boun...@lists.squid-cache.org
> > <mailto:squid-users-boun...@lists.squid-cache.org>
> > > <mailto:squid-users-boun...@lists.squid-cache.org
> > <mailto:squid-users-boun...@lists.squid-cache.org>>> On Behalf Of
> > > Andrey K
> > > Sent: Friday, June 9, 2023 10:03
> > > To: Squid Users <squid-users@lists.squid-cache.org
> > <mailto:squid-users@lists.squid-cache.org>
> > > <mailto:squid-users@lists.squid-cache.org
> > <mailto:squid-users@lists.squid-cache.org>>>; Amos Jeffries
> > > <squ...@treenet.co.nz <mailto:squ...@treenet.co.nz>
> > <mailto:squ...@treenet.co.nz <mailto:squ...@treenet.co.nz>>>
> > > Subject: [squid-users] 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@lists.squid-cache.org
> > <mailto:squid-users@lists.squid-cache.org>
> > > <mailto:squid-users@lists.squid-cache.org
> > <mailto:squid-users@lists.squid-cache.org>>
> > > 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@lists.squid-cache.org
> > <mailto:squid-users@lists.squid-cache.org>
> > > http://lists.squid-cache.org/listinfo/squid-users
> > <http://lists.squid-cache.org/listinfo/squid-users>
> >
> > _______________________________________________
> > squid-users mailing list
> > squid-users@lists.squid-cache.org
> > <mailto:squid-users@lists.squid-cache.org>
> > http://lists.squid-cache.org/listinfo/squid-users
> > <http://lists.squid-cache.org/listinfo/squid-users>
> >
>
>
_______________________________________________
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users
