Re: [squid-users] 4.10 crash
26.02.2020 11:42, Dmitry Melekhov пишет: Hello! see this in log, after this squid dies. 2020/02/26 11:17:47 kid1| UPGRADE WARNING: URL rewriter reponded with garbage ' 192.168.23.54/ABDRASHITOV-RR.p98a3.belkam.com abdrashitovrr CONNECT myip=192.168.22.254 myport=8090'. Future Squid wil l treat this as part of the URL. 2020/02/26 11:17:48 kid1| assertion failed: MemBuf.cc:354: "new_cap > (size_t) capacity" from systemctl status: фев 26 11:17:48 inetgw2 squid[1167]: Squid Parent: squid-1 process 11576 exited due to signal 6 with фев 26 11:17:48 inetgw2 squid[1167]: Squid Parent: squid-1 process 11576 will not be restarted for 3 фев 26 11:17:48 inetgw2 squid[1167]: Exiting due to repeated, frequent failures I see this several times, have no idea what caused this, even if this is redirector error, squid should not crash... Is there any way to fix this? Thank you! btw, looks like here is request, which causes problem - time can be different, we hit this several times... 1582701916.487 34 192.168.23.54 TCP_MISS/404 723 GET http://detectportal.firefox.com/success.txt192.168.23.54/ABDRASHITOV-RR.p98a3.belkam.comabdrashitovrrGETmyip=192.168.22.254myport=8090 abdrashitovrr HIER_DIRECT/212.188.32.137 application/xml ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
[squid-users] 4.10 crash
Hello! see this in log, after this squid dies. 2020/02/26 11:17:47 kid1| UPGRADE WARNING: URL rewriter reponded with garbage ' 192.168.23.54/ABDRASHITOV-RR.p98a3.belkam.com abdrashitovrr CONNECT myip=192.168.22.254 myport=8090'. Future Squid wil l treat this as part of the URL. 2020/02/26 11:17:48 kid1| assertion failed: MemBuf.cc:354: "new_cap > (size_t) capacity" from systemctl status: фев 26 11:17:48 inetgw2 squid[1167]: Squid Parent: squid-1 process 11576 exited due to signal 6 with фев 26 11:17:48 inetgw2 squid[1167]: Squid Parent: squid-1 process 11576 will not be restarted for 3 фев 26 11:17:48 inetgw2 squid[1167]: Exiting due to repeated, frequent failures I see this several times, have no idea what caused this, even if this is redirector error, squid should not crash... Is there any way to fix this? Thank you! ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
[squid-users] Docker squid container setup
hi team, Could anyone guide me with details on how to setup squid ( sibling) in dockerized containers? I have them running n standalone machine, thinking to get this do the same with the container.Thanks,Prabu -- Sent from: http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-Users-f1019091.html ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] Missing ICAP header in adaptation_masterx_shared_names in RESPMOD only
On 2/25/20 11:17 AM, Felipe Polanco wrote: > I'm consuming an ICAP service that requires Squid to send the masterx > shared names header in the RESPMOD call. What service or Squid configuration creates that header? > For an unknown reason, the header is missing if squid is sending RESPMOD > only to the ICAP server. > > If I enable REQMOD and RESPMOD then the header is attached. > Is this a bug or intentional? Difficult to say for sure without more info, but perhaps the REQMOD service was creating the header, and when you removed that service, the header was gone, and Squid had nothing to share with the RESPMOD service? If the removed REQMOD service was not creating that header, then where did the header come from? From http://www.squid-cache.org/Doc/config/adaptation_masterx_shared_names/: > Squid will store and forward the set entry to subsequent adaptation > transactions within the same master transaction scope. Note the word "subsequent" in the above documentation paragraph. I suspect that with only one (RESPMOD) service, nothing else may be creating that header before Squid starts that RESPMOD transaction. HTH, Alex. ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] About intercept https
squid configuration: Squid Cache: Version 4.10 Service Name: squid This binary uses OpenSSL 1.1.1 11 Sep 2018. For legal restrictions on distribution see https://www.openssl.org/source/license.html configure options: '--datadir=/usr/share/squid' '--sysconfdir=/etc/squid' '--libexecdir=/usr/lib/squid' '--mandir=/usr/share/man' '--enable-inline' '--disable-arch-native' '--disable-ipv6' '--enable-async-io=8' '--enable-storeio=ufs,aufs,diskd,rock' '--enable-removal-policies=lru,heap' '--enable-delay-pools' '--enable-cache-digests' '--enable-icap-client' '--enable-follow-x-forwarded-for' '--enable-auth-basic=DB,fake,getpwnam,LDAP,NCSA,NIS,PAM,POP3,RADIUS,SASL,SMB' '--enable-url-rewrite-helpers=fake' '--enable-eui' '--enable-esi' '--enable-icmp' '--enable-zph-qos' '--enable-ecap' '--enable-ssl' '--enable-ssl-crtd' '--with-openssl' '--disable-translation' '--with-swapdir=/var/spool/squid' '--with-logdir=/var/log/squid' '--with-pidfile=/var/run/squid.pid' '--with-filedescriptors=65536' '--with-large-files' '--with-default-user=proxy' ip firewall mangle & route on Mikrotik: /ip firewall mangle add chain=prerouting src-address=10.3.198.0/24 dst-port=80 protocol=tcp action=mark-routing new-routing-mark=to_squid add chain=prerouting src-address=10.3.198.0/24 dst-port=443 protocol=tcp action=mark-routing new-routing-mark=to_squid /ip route add disabled=no distance=1 dst-address=0.0.0.0/0 gateway=10.3.198.224 routing-mark=to_squid scope=30 target-scope=10 iptables on Ubuntu: # redirect HTTP to locally installed Squid instance iptables -t nat -A PREROUTING -i ens160 -p tcp --dport 80 -j REDIRECT --to-ports 3129 # redirect HTTPS to locally installed Squid instance iptables -t nat -A PREROUTING -i ens160 -p tcp --dport 443 -j REDIRECT --to-ports 3130 access.log: 1581426261.762 7924 10.3.198.8 TCP_TUNNEL/200 4602 CONNECT facebook.com:443 - ORIGINAL_DST/facebook.com - DNS lookup 1 splice facebook.com 1581426261.762 2598 10.3.198.8 TCP_TUNNEL/200 105429 CONNECT www.softserveinc.com:443 - ORIGINAL_DST/www.softserveinc.com - DNS lookup - splice www.softserveinc.com 1581426262.495 2073 10.3.198.8 NONE/200 0 CONNECT 185.60.216.35:443 - HIER_NONE/- - DNS lookup - splice www.facebook.com 1581426264.059 2101 10.3.198.8 NONE/200 0 CONNECT 185.60.216.19:443 - HIER_NONE/- - DNS lookup - splice static.xx.fbcdn.net 1581426267.809 22 10.3.198.8 NONE/200 0 CONNECT 104.17.212.204:443 - HIER_NONE/- - DNS lookup 22 splice js.hs-scripts.com 1581426269.372 2037 10.3.198.8 NONE/200 0 CONNECT 185.60.216.35:443 - HIER_NONE/- - DNS lookup - splice www.facebook.com 1581426269.376 2041 10.3.198.8 NONE/200 0 CONNECT 152.199.19.161:443 - HIER_NONE/- - DNS lookup - splice cdn-cws-prod.azureedge.net 1581426270.172 2069 10.3.198.8 NONE/200 0 CONNECT 185.60.216.19:443 - HIER_NONE/- - DNS lookup - splice connect.facebook.net 1581426270.206 2103 10.3.198.8 NONE/200 0 CONNECT 216.58.215.78:443 - HIER_NONE/- - DNS lookup - splice www.google-analytics.com 1581426270.213 2109 10.3.198.8 NONE/200 0 CONNECT 185.63.144.5:443 - HIER_NONE/- - DNS lookup 1 splice px.ads.linkedin.com 1581426270.219 2116 10.3.198.8 NONE/200 0 CONNECT 216.58.215.98:443 - HIER_NONE/- - DNS lookup - splice googleads.g.doubleclick.net 1581426271.763 7703 10.3.198.8 TCP_TUNNEL/200 443 CONNECT static.xx.fbcdn.net:443 - ORIGINAL_DST/static.xx.fbcdn.net - DNS lookup - splice static.xx.fbcdn.net 1581426271.763 2391 10.3.198.8 TCP_TUNNEL/200 3393 CONNECT www.facebook.com:443 - ORIGINAL_DST/www.facebook.com - DNS lookup - splice www.facebook.com 1581426271.763 1544 10.3.198.8 TCP_TUNNEL/200 2891 CONNECT googleads.g.doubleclick.net:443 - ORIGINAL_DST/googleads.g.doubleclick.net - DNS lookup 2 splice googleads.g.doubleclick.net 1581426271.764 1551 10.3.198.8 TCP_TUNNEL/200 4093 CONNECT px.ads.linkedin.com:443 - ORIGINAL_DST/px.ads.linkedin.com - DNS lookup - splice px.ads.linkedin.com 1581426271.764 9268 10.3.198.8 TCP_TUNNEL/200 2012 CONNECT www.facebook.com:443 - ORIGINAL_DST/www.facebook.com - DNS lookup 1 splice www.facebook.com 1581426271.764 2388 10.3.198.8 TCP_TUNNEL/200 10117 CONNECT cdn-cws-prod.azureedge.net:443 - ORIGINAL_DST/cdn-cws-prod.azureedge.net - DNS lookup - splice cdn-cws-prod.azureedge.net 1581426271.764 3954 10.3.198.8 TCP_TUNNEL/200 1036 CONNECT js.hs-scripts.com:443 - ORIGINAL_DST/js.hs-scripts.com - DNS lookup 1 splice js.hs-scripts.com 1581426271.764 1558 10.3.198.8 TCP_TUNNEL/200 1816 CONNECT www.google-analytics.com:443 - ORIGINAL_DST/www.google-analytics.com - DNS lookup - splice www.google-analytics.com 1581426271.764 1592 10.3.198.8 TCP_TUNNEL/200 150372 CONNECT connect.facebook.net:443 - ORIGINAL_DST/connect.facebook.net - DNS lookup 2 splice connect.facebook.net Squid.conf: acl localnet src 10.3.198.0/24 acl SSL_ports port 443 acl Safe_ports port 80 # http acl Safe_ports port 21 # ftp acl Safe_ports port 443 # https acl Safe_ports port 70 # gopher acl
Re: [squid-users] About intercept https
On Tuesday 25 February 2020 at 20:49:25, Yurii wrote: > Hi to all. I need help. > The task is to configure squid in intercept mode to proxy http/https > traffic. I cannot view any of the pastebin links you provide below. Please just cut and paste the information into an email reply, so we can read it here and then hopefully advise you. > Installed Squid 4.10 (configuration: https://pastebin.com/Gg2VPr0v) Ubuntu > 18.04. Redirect traffic from Mikrotik to Ubuntu (ip firewall mangle & ip > route: https://pastebin.com/5UrNcsEc), and there 80, 443 traffic to Squid > 3129, 3130 (iptables: https://pastebin.com/kXxy8zHb). > > DNS squid use the same as on client machines. In squid.conf /dns_v4_first > on/. DNS lookup time in access.log: https://pastebin.com/zdwHjRHk > > There is a problem - long loading of http/https pages. In the case of > https - /"Creating a secure connection"/, http - /"Waiting..."/ and so for > 5-10 seconds. > Please, tell me what is wrong? > > /*Squid.conf* is here - https://pastebin.com/MX5mNi5q > *Localnet* - 10.3.198.0/24 > *Mikrotik* - 10.3.198.254 > *Squid* - 10.3.198.224/ Regards, Antony. -- Numerous psychological studies over the years have demonstrated that the majority of people genuinely believe they are not like the majority of people. Please reply to the list; please *don't* CC me. ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
[squid-users] About intercept https
Hi to all. I need help. The task is to configure squid in intercept mode to proxy http/https traffic. Installed Squid 4.10 (configuration: https://pastebin.com/Gg2VPr0v) Ubuntu 18.04. Redirect traffic from Mikrotik to Ubuntu (ip firewall mangle & ip route: https://pastebin.com/5UrNcsEc), and there 80, 443 traffic to Squid 3129, 3130 (iptables: https://pastebin.com/kXxy8zHb). DNS squid use the same as on client machines. In squid.conf /dns_v4_first on/. DNS lookup time in access.log: https://pastebin.com/zdwHjRHk There is a problem - long loading of http/https pages. In the case of https - /"Creating a secure connection"/, http - /"Waiting..."/ and so for 5-10 seconds. Please, tell me what is wrong? /*Squid.conf* is here - https://pastebin.com/MX5mNi5q *Localnet* - 10.3.198.0/24 *Mikrotik* - 10.3.198.254 *Squid* - 10.3.198.224/ -- Sent from: http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-Users-f1019091.html ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
[squid-users] Missing ICAP header in adaptation_masterx_shared_names in RESPMOD only
Hi, I'm consuming an ICAP service that requires Squid to send the masterx shared names header in the RESPMOD call. For an unknown reason, the header is missing if squid is sending RESPMOD only to the ICAP server. If I enable REQMOD and RESPMOD then the header is attached. Is this a bug or intentional? ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] several sites - cloudflare not working with ssl-bump ...
On Tue, February 25, 2020 06:30, Amos Jeffries wrote: > On 25/02/20 5:00 am, Walter H. wrote: >> Hello, >> >> can someone explain, why >> sites as https://dnslytics.com/ >> do not work any more if 'server-first', >> they only work with 'client-first' why? >> > > Not with the lack of information supplied. > > Amos part of my squid.conf acl step1 at_step SslBump1 acl step2 at_step SslBump2 acl step3 at_step SslBump3 acl nobumpsites ssl::server_name "/etc/squid/sslnobumpsites-acl.squid" # this doesn't work, my own Site also only with SNI works ssl_bump peek step1 ssl_bump splice nobumpsites ssl_bump stare step2 ssl_bump bump all # this works #ssl_bump client-first # this doesn't work with these sites #ssl_bump server-first even WGET shows this: ERROR: no certificate subject alternative name matches which means that SNI isn't correctly handled, but why and which part of the chain is causing this? this problem is since e.g. dnslytics.com got a new SSL certificate this year Thanks, Walter ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
