<div dir="ltr"><div>Hello, Alex,</div><div><br></div><div>Thanks for your comments.</div><div><br></div>> if you want more definitive answers, please share a<br>> compressed ALL,9 log while reproducing the problem with that curl<br>> transaction:<div><br></div><div>A link to the uploaded ALL,9 log is: <a href="https://drive.google.com/file/d/1kC8oV8WAelsBYoZDoqnNsnyd7cfYOoDi/view?usp=sharing">https://drive.google.com/file/d/1kC8oV8WAelsBYoZDoqnNsnyd7cfYOoDi/view?usp=sharing</a></div><div><br></div><div><span class="gmail-im" style="color:rgb(80,0,80)">>> I think we could ignore these warnings as squid works perfectly<br><br></span>> 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></div><div><br></div><div>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</div><div><br></div><div>> 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></div><div><br></div><div>Thank you, Alex, I will try this workaround after you have time to take a look at ALL,9 log.</div><div><br></div><div>Kind regards,</div><div> Ankor.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">чт, 22 июн. 2023 г. в 20:11, Alex Rousskov <<a href="mailto:rousskov@measurement-factory.com">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/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 /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>
> <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>> - 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>
> 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>> - 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>> text/html - - -<br>
> <br>
> The cache.log is available at the link: <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><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 used in <br>
> context without an HTTP request. Assuming mismatch.<br>
> 2023/06/22 10:59:57.884 kid6| WARNING: domdst_SIProxy ACL is used in <br>
> context without an HTTP request. Assuming mismatch.<br>
> 2023/06/22 10:59:58.536 kid6| WARNING: domdst_SIProxy ACL is 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 tcp_outgoing_address is <br>
used without a request. Some of those places look like Squid bugs to me. <br>
Some look legitimate. Again, I cannot tell whether your Squid is hitting <br>
one of those places; if you want more definitive answers, please 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><br>
<br>
> The domdst_SIProxy ACL is used only to change the outgoing address for <br>
> specific domains<br>
<br>
> The test URL <a href="https://archive.org" rel="noreferrer" target="_blank">https://archive.org</a> is not in the domdst_SIProxy list.<br>
<br>
That fact does not matter -- the warnings are printed (and the 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 "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>
> <br>
> Hey Ankor,<br>
> <br>
> There is some missing context so I would be able to reproduce 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 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>>> 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>>>; 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>
> 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 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 used in<br>
> context without an HTTP request. Assuming mismatch.<br>
> <br>
> I found a similar case:<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>> where Amos suggested using a patch as a solution.<br>
> We have Squid Version 5.5. Is there a similar patch for our 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>
> <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>
> <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>
<a href="http://lists.squid-cache.org/listinfo/squid-users" rel="noreferrer" target="_blank">http://lists.squid-cache.org/listinfo/squid-users</a><br>
</blockquote></div>