Hello,
I am sorry to interrupt the conversation, but 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]
So the configuration is reliable.
Alex, maybe there are other factors that I'm not considering?
Kind regards,
Ankor.
>> # Google via ISP2
>> acl google dstdomain .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 <alexm...@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 <
> rouss...@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
>>
>>
>> BTW, more about transaction annotations is available at
>> https://lists.squid-cache.org/pipermail/squid-users/2023-April/025784.html
>>
>>
>> HTH,
>>
>> Alex.
>>
>>
>>
>> > вс, 22 дек. 2024 г. в 22:47, Alex Rousskov
>> > <rouss...@measurement-factory.com
>> > <mailto:rouss...@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>
>> > > 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 <alexm...@gmail.com
>> > <mailto:alexm...@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@lists.squid-cache.org
>> > <mailto:squid-users@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@lists.squid-cache.org
>> > <mailto:squid-users@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@lists.squid-cache.org
>> https://lists.squid-cache.org/listinfo/squid-users
>>
> _______________________________________________
> squid-users mailing list
> squid-users@lists.squid-cache.org
> https://lists.squid-cache.org/listinfo/squid-users
>
_______________________________________________
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users
