On 2024-12-23 21:59, Andrey K wrote:
in my opinion, the
ACL used in the policy is fast, as stated in the documentation
(https://www.squid-cache.org/Doc/config/acl/):
acl aclname dstdomain [-n] .foo.com ...
# Destination server from URL [fast]
That documentation is misleading: In some cases, intended dstdomain
evaluation is slow. In other cases, it is fast. Thus, in general,
dstdomain should be treated as a slow ACL. Technically, one can define
the term "slow ACL" in such a way that dstdomain would be considered
"fast"[0], but I do not recommend using such definitions because (when
used by human admins) they are likely to lead to unreliable configurations.
N.B. "dstdomain -n" is a fast ACL, but "dstdomain -n x" does not match
in certain cases where "dstdomain x" would match.
SquidAcl FAQ entry[1] similarly misleads when listing dstdomain on the
"Fast ACLs include" list, but the following (abridged) text on that same
FAQ page is correct with respect to asynchronous (a.k.a. "slow") DNS
lookups that dstdomain performs (or is intended to perform):
> acl Cooking2 dstdomain example.test
>
Note that when IP addresses are used
(instead of domain names), Squid may have to do a DNS lookup to
determine whether the ACL matches: If a domain name for the IP
address is already in the Squid’s “FQDN cache”, then Squid can
immediately compare the destination domain against the access
controls. Otherwise, Squid does an asynchronous reverse DNS lookup
and evaluates the ACL after that lookup is over.
>
Asynchronous lookups are done for http_access and other directives
that support so called “slow” ACLs. If a directive does not support a
required asynchronous DNS lookup, then modern Squids use “none”
instead of the actual domain name to determine whether a dstdomain
ACL matches, but you should not rely on that behavior. To disable DNS
lookups, use the “-n” ACL option (where supported).
[0]: Depending on the "fast ACL" definition, the "none" comparison
documented a few lines above can be used as an excuse to categorize
dstdomain as a fast ACL, but "you should not rely on that behavior"
advice is correct, and configurations that are not using that trick
consistently/correctly (while using dstdomain with directives that do
not support slow ACLs) are likely unreliable.
[1]: https://wiki.squid-cache.org/SquidFaq/SquidAcl
HTH,
Alex.
# Google via ISP2
acl google dstdomain .google.com <http://google.com/>
tcp_outgoing_address REAL_IP_ISP2 google
> Please note that the above configuration usually "works" but is
> unreliable and unsupported: tcp_outgoing_address directive does not
> support slow ACLs and your ACL named google is a slow ACL.
пн, 23 дек. 2024 г. в 14:33, A. Pechenin <alexmrrc@xxxxxxxxx
<mailto:alexmrrc@xxxxxxxxx>>:
Unfortunately, there is no greater clarity in the practical
application of the techniques used in the topics you have provided.
I would be grateful for practice specifically in my case for a
better understanding of the work.
пн, 23 дек. 2024 г. в 00:42, Alex Rousskov
<rousskov@xxxxxxxxxxxxxxxxxxxxxxx
<mailto:rousskov@xxxxxxxxxxxxxxxxxxxxxxx>>:
On 2024-12-22 15:13, A. Pechenin wrote:
> could you please explain in more detail and in my case what
needs to
> be added to "strengthen and ensure" the operation of my solution?
Does Q2 and Q3 at [1] help? If not, I hope that others can guide
you
through using a never-matching http_access rule and
annotate_transaction
ACL side effects to improve reliability of your current
configuration.
[1]
https://lists.squid-cache.org/pipermail/squid-dev/2021-January/009643.html <https://lists.squid-cache.org/pipermail/squid-dev/2021-January/009643.html>
BTW, more about transaction annotations is available at
https://lists.squid-cache.org/pipermail/squid-users/2023-April/025784.html <https://lists.squid-cache.org/pipermail/squid-users/2023-April/025784.html>
HTH,
Alex.
> вс, 22 дек. 2024 г. в 22:47, Alex Rousskov
> <rousskov@xxxxxxxxxxxxxxxxxxxxxxx
<mailto:rousskov@xxxxxxxxxxxxxxxxxxxxxxx>
> <mailto:rousskov@xxxxxxxxxxxxxxxxxxxxxxx
<mailto:rousskov@xxxxxxxxxxxxxxxxxxxxxxx>>>:
>
> On 2024-12-22 08:13, A. Pechenin wrote:
> > The reason and solution were not simple and obvious at
first glance.
> > I have two providers accessing the gateway, the main
and backup
> > channels, and automatic switching is configured when the
> connection on
> > the main channel is lost.
> > To check, I switched the proxy server to the second
channel and the
> > problem with partial unavailability of Google services
was solved.
> >
> > I returned it back, used a simple formula in the
configuration
> file with
> > subsequent partial adjustment of ipfw.
>
> Glad you found a solution! Diagnosing problems related to
CONNECT
> tunnels is difficult because Squid (playing a role of a
dumb TCP relay)
> is often unaware of problems experienced by clients and
origin servers.
>
>
> > # Google via ISP2
> > acl google dstdomain .google.com <http://google.com>
<http://google.com <http://google.com>>
> > tcp_outgoing_address REAL_IP_ISP2 google
>
> Please note that the above configuration usually "works"
but is
> unreliable and unsupported: tcp_outgoing_address
directive does not
> support slow ACLs and your ACL named google is a slow ACL.
>
> For a more reliable solution, consider annotating
google-matching
> transaction at http_access check time and then using
those annotations
> at tcp_outgoing_address check time. For a somewhat
related example,
> look
> for "markSpecial" in squid.conf.documented or search this
mailing list
> archives for annotate_transaction discussions.
>
>
> HTH,
>
> Alex.
>
>
> > сб, 21 дек. 2024 г. в 20:26, A. Pechenin
<alexmrrc@xxxxxxxxx <mailto:alexmrrc@xxxxxxxxx>
> <mailto:alexmrrc@xxxxxxxxx <mailto:alexmrrc@xxxxxxxxx>>>:
> >
> > This week, when connecting users through a proxy
server, some
> Google
> > services became inaccessible, such as Calendar,
Translator, user
> > profile.
> >
> > When clicking on the services section in the
browser on the
> Google
> > portal, the page does not open and then a
connection error is
> > displayed. When directly going to the calendar
section, the
> > connection also hangs for a long time without
loading the
> page. At
> > the same time, the Google home page, mail, search
work.
> >
> > Transparent proxying is not used.
> > Viewing the proxy server logs did not add any
understanding, all
> > requests are processed correctly and no errors or
> prohibitions are
> > observed. There are no other problems with the
unavailability
> of any
> > sites.
> >
> > When connecting directly (bypassing the proxy
server), all Google
> > services work completely correctly.
> > The platform on which the problem was suddenly
discovered:
> > FreeBSD 13.2-RELEASE-p9
> > Squid 6.6
> >
> > A new separate server was deployed for objectivity and
> finding the
> > cause, but the problem was also reproduced there,
its platform.
> > FreeBSD 13.4-RELEASE-p2
> > Squid 6.10
> >
> > I tried using the default configuration file
(recommended minimum
> > configuration) to eliminate the problem in my
working squid.conf,
> > but the problem remained
> >
> > I repeat, the problem reproduced suddenly, no
changes were
> made to
> > the proxy server configuration on our side, no
problems with
> Google
> > have arisen for many years. What should I pay
attention to in the
> > Squid configuration? Any idea
> >
> >
> > _______________________________________________
> > squid-users mailing list
> > squid-users@xxxxxxxxxxxxxxxxxxxxx
<mailto:squid-users@xxxxxxxxxxxxxxxxxxxxx>
> <mailto:squid-users@xxxxxxxxxxxxxxxxxxxxx
<mailto:squid-users@xxxxxxxxxxxxxxxxxxxxx>>
> > https://lists.squid-cache.org/listinfo/squid-users
<https://lists.squid-cache.org/listinfo/squid-users>
> <https://lists.squid-cache.org/listinfo/squid-users
<https://lists.squid-cache.org/listinfo/squid-users>>
>
> _______________________________________________
> squid-users mailing list
> squid-users@xxxxxxxxxxxxxxxxxxxxx
<mailto:squid-users@xxxxxxxxxxxxxxxxxxxxx>
> <mailto:squid-users@xxxxxxxxxxxxxxxxxxxxx
<mailto:squid-users@xxxxxxxxxxxxxxxxxxxxx>>
> https://lists.squid-cache.org/listinfo/squid-users
<https://lists.squid-cache.org/listinfo/squid-users>
> <https://lists.squid-cache.org/listinfo/squid-users
<https://lists.squid-cache.org/listinfo/squid-users>>
>
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
<mailto:squid-users@xxxxxxxxxxxxxxxxxxxxx>
https://lists.squid-cache.org/listinfo/squid-users
<https://lists.squid-cache.org/listinfo/squid-users>
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
<mailto:squid-users@xxxxxxxxxxxxxxxxxxxxx>
https://lists.squid-cache.org/listinfo/squid-users
<https://lists.squid-cache.org/listinfo/squid-users>
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.squid-cache.org/listinfo/squid-users
