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.
>> 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 <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>: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
> <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>
> > 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>>:
> >
> > This week, when connecting users through a proxy server, some
> > services became inaccessible, such as Calendar, Translator, user
> > profile.
> >
> > When clicking on the services section in the browser on the
> > 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
> > 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>
> > 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
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.squid-cache.org/listinfo/squid-users
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx https://lists.squid-cache.org/listinfo/squid-users
