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