[squid-users] SQUID problem with unavailability of Google services
Alex Rousskov
rousskov at measurement-factory.com
Tue Dec 24 14:56:25 UTC 2024
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 at gmail.com
> <mailto:alexmrrc at gmail.com>>:
>
> 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 at measurement-factory.com
> <mailto:rousskov at measurement-factory.com>>:
>
> 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 at measurement-factory.com
> <mailto:rousskov at measurement-factory.com>
> > <mailto:rousskov at measurement-factory.com
> <mailto:rousskov at measurement-factory.com>>>:
> >
> > 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 at gmail.com <mailto:alexmrrc at gmail.com>
> > <mailto:alexmrrc at gmail.com <mailto:alexmrrc at gmail.com>>>:
> > >
> > > 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 at lists.squid-cache.org
> <mailto:squid-users at lists.squid-cache.org>
> > <mailto:squid-users at lists.squid-cache.org
> <mailto:squid-users at lists.squid-cache.org>>
> > > 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 at lists.squid-cache.org
> <mailto:squid-users at lists.squid-cache.org>
> > <mailto:squid-users at lists.squid-cache.org
> <mailto:squid-users at lists.squid-cache.org>>
> > 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 at lists.squid-cache.org
> <mailto:squid-users at lists.squid-cache.org>
> https://lists.squid-cache.org/listinfo/squid-users
> <https://lists.squid-cache.org/listinfo/squid-users>
>
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> <mailto:squid-users at lists.squid-cache.org>
> https://lists.squid-cache.org/listinfo/squid-users
> <https://lists.squid-cache.org/listinfo/squid-users>
>
More information about the squid-users
mailing list