[squid-users] Using tcp_outgoing_address with ACL
Andrey K
ankor2023 at gmail.com
Fri Jun 23 12:05:16 UTC 2023
Hello, Alex,
Thanks for your comments.
> if you want more definitive answers, please share a
> compressed ALL,9 log while reproducing the problem with that curl
> transaction:
A link to the uploaded ALL,9 log is:
https://drive.google.com/file/d/1kC8oV8WAelsBYoZDoqnNsnyd7cfYOoDi/view?usp=sharing
>> 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 at 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>
> >
> > 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> - HIER_DIRECT/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/> - HIER_DIRECT/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
>
> > 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
>
> > The domdst_SIProxy ACL is used only to change the outgoing address for
> > specific domains
>
> > The test URL 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 at gmail.com
> > <mailto:ngtech1ltd at 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-bounces at lists.squid-cache.org
> > <mailto:squid-users-bounces at lists.squid-cache.org>> On Behalf Of
> > Andrey K
> > Sent: Friday, June 9, 2023 10:03
> > To: Squid Users <squid-users at lists.squid-cache.org
> > <mailto:squid-users at lists.squid-cache.org>>; Amos Jeffries
> > <squid3 at treenet.co.nz <mailto:squid3 at 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>
> 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 at lists.squid-cache.org
> > <mailto:squid-users at 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 at lists.squid-cache.org
> > http://lists.squid-cache.org/listinfo/squid-users
>
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20230623/fd3ed01a/attachment.htm>
More information about the squid-users
mailing list