I have created an example how to use and match usernames to tcp_outgoing_ports
https://github.com/elico/vagrant-squid-outgoing-addresses its better to use a single port with different user names (if possible). Let me know what do you think about the solution I am offering and if the example is understandable. Eliezer בתאריך יום ה׳, 18 בנוב׳ 2021, 22:56, מאת Graminsta < marcelorodr...@graminsta.com.br>: > Tks for the answers. > > Considerations: > > 1- "Please note that you are allowing authenticated clients to send traffic > to unsafe ports. For example, they can CONNECT to non-SSL ports. You may > want to reorder the above rules if that is not what you want." > > ANSWER: > Tks for the advice, I already had it changed. > > > 2- "However, you should also ask yourself another question: "Why am I using > multiple http_ports if all I care about is who uses which > tcp_outgoing_address?". The listening ports have virtually nothing to do > with tcp_outgoing_address..." > > ANSWER: > Because I have to route each http_port to specific tcp_outgoing_address. > I have several customers per VPS. > Each one uses like 10 different ports to direct connections through > different IPv6s. > > 3- "Use http_access to deny authenticated users connected to wrong ports." > > ANSWER: > So, in this scenario, how can I prevent users in the same users list to > access ports that not belong to them. > How to deny it in http_access rules? > > Marcelo > > -----Mensagem original----- > De: squid-users [mailto:squid-users-boun...@lists.squid-cache.org] Em nome > de squid-users-requ...@lists.squid-cache.org > Enviada em: terça-feira, 16 de novembro de 2021 15:23 > Para: squid-users@lists.squid-cache.org > Assunto: squid-users Digest, Vol 87, Issue 19 > > Send squid-users mailing list submissions to > squid-users@lists.squid-cache.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.squid-cache.org/listinfo/squid-users > or, via email, send a message with subject or body 'help' to > squid-users-requ...@lists.squid-cache.org > > You can reach the person managing the list at > squid-users-ow...@lists.squid-cache.org > > When replying, please edit your Subject line so it is more specific than > "Re: Contents of squid-users digest..." > > > Today's Topics: > > 1. Multi-clients VPS - Authentication been shared. (Graminsta) > 2. Re: Too many ERROR: Collapsed forwarding queue overflow for > kid2 at 1024 items (Lou?ansk? Luk??) > 3. Re: Stable Squid Version for production on Linux (David Touzeau) > 4. Re: Too many ERROR: Collapsed forwarding queue overflow for > kid2 at 1024 items (Alex Rousskov) > 5. Re: Multi-clients VPS - Authentication been shared. > (Alex Rousskov) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 16 Nov 2021 13:53:52 -0300 > From: "Graminsta" <marcelorodr...@graminsta.com.br> > To: <squid-users@lists.squid-cache.org> > Subject: [squid-users] Multi-clients VPS - Authentication been shared. > Message-ID: <005e01d7db0a$8ab2ab80$a0180280$@graminsta.com.br> > Content-Type: text/plain; charset="us-ascii" > > Hello friends, > > > > I'm using these user authentication lines in squid.conf based on user's > authentication list: > > > > auth_param basic program /usr/lib/squid/basic_ncsa_auth /etc/squid/users > > auth_param basic children 5 > > auth_param basic realm Squid proxy-caching web server > > auth_param basic credentialsttl 2 hours > > auth_param basic casesensitive off > > > > http_access allow localhost > > acl clientes proxy_auth REQUIRED > > http_access allow clientes > > http_access deny !Safe_ports > > http_access deny CONNECT !SSL_ports > > http_access allow localhost manager > > http_access deny manager > > http_access deny all > > > > #List of outgoings (all IPs are fake) > > http_port 181.111.11.111:4000 name=3 > > acl ip3 myportname 3 > > tcp_outgoing_address 2804:1934:2E1::3D6 ip3 > > > > http_port 181.111.11.112:4001 name=4 > > acl ip4 myportname 4 > > tcp_outgoing_address 2804:1934:3a8::3D7 ip4 > > > > The problem is that everyone whom is in the users file are allow to use all > tcp_outgoing_address. > > If a smarter client scans for open IPs and ports will be able to find these > outgoings. > > > > How can I restrict each user to their own tcp_outgoing_address output? > > > > Tks. > > Marcelo > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > < > http://lists.squid-cache.org/pipermail/squid-users/attachments/20211116/69f > b0a22/attachment-0001.htm > <http://lists.squid-cache.org/pipermail/squid-users/attachments/20211116/69fb0a22/attachment-0001.htm> > > > > ------------------------------ > > Message: 2 > Date: Tue, 16 Nov 2021 18:00:56 +0100 > From: Lou?ansk? Luk?? <loucansky.lu...@kjj.cz> > To: "Alex Rousskov" <rouss...@measurement-factory.com>, "Squid Users" > <squid-users@lists.squid-cache.org> > Subject: Re: [squid-users] Too many ERROR: Collapsed forwarding queue > overflow for kid2 at 1024 items > Message-ID: > <72dd5d5cf661b5459dc08a060bf26b5301089...@kjj-server.kjj.local> > Content-Type: text/plain; charset="windows-1250" > > Ok - I will try to backport it from that patch into the v5 tree I've > downloaded today. As we were using the mentioned build I came across these > new assertions: > > 2021/11/16 10:29:46 kid1| assertion failed: StoreMap.cc:241: > "anchorAt(anchorId).reading()" > 2021/11/16 11:32:51 kid2| assertion failed: Transients.cc:221: "old == e" > 2021/11/16 13:02:09 kid2| assertion failed: Transients.cc:221: "old == e" > 2021/11/16 13:52:05 kid2| assertion failed: Transients.cc:221: "old == e" > 2021/11/16 14:29:41 kid2| assertion failed: store.cc:1108: "store_status == > STORE_PENDING" > 2021/11/16 15:26:15 kid1| assertion failed: Transients.cc:221: "old == e" > 2021/11/16 17:40:21 kid1| assertion failed: cbdata.cc:372: "c->locks > 0" > 2021/11/16 17:40:44 kid1| assertion failed: cbdata.cc:115: "cookie == > ((long)this ^ Cookie)" > > > (no config changes) > > My 1w cache.log is about 300MB - without elevated debug options (debug > options ALL,1) - so it?s not easy to find something relevant with "9" > options enabled... > > LL > > -----Original Message----- > From: Alex Rousskov [mailto:rouss...@measurement-factory.com] > Sent: Tuesday, November 16, 2021 3:42 PM > To: Lou?ansk? Luk??; Squid Users > Subject: Re: [squid-users] Too many ERROR: Collapsed forwarding queue > overflow for kid2 at 1024 items > > On 11/16/21 4:38 AM, Lou?ansk? Luk?? wrote: > > is it going to be patched only in the v6 version? > > I hope the existing fix applies to v5 cleanly, and I am ready to help with > backporting if it does not. Beyond that, it is in the maintainer hands. I > cannot predict whether or when the fix will be officially merged into v5 > because I do not understand how those decisions are made. > > > > Anyway - in the morning I run debug with 20,9 to see: > > ... > > 2021/11/16 09:02:06.496 kid2| assertion failed: Transients.cc:221: "old > == > e" > > Unfortunately, I cannot see the cause of the assertion in this > short/partial > trace -- the problematic actions happened before the trace or were not > logged during the trace. > > Patching your Squid with commit 5210df4 is the best next step IMO. If that > patch does not help, then there are probably other bugs that we need to fix > in v5 (at least). > > > HTH, > > Alex. > > > > -----Original Message----- > > From: Alex Rousskov [mailto:rouss...@measurement-factory.com] > > Sent: Monday, November 15, 2021 5:17 PM > > To: Squid Users > > Cc: Lou?ansk? Luk?? > > Subject: Re: [squid-users] Too many ERROR: Collapsed forwarding queue > > overflow for kid2 at 1024 items > > > > On 11/15/21 7:43 AM, Lou?ansk? Luk?? wrote: > > > >> 2021/11/14 10:13:30 kid2| assertion failed: Transients.cc:221: "old == > e" > >> 2021/11/15 08:37:36 kid2| assertion failed: Transients.cc:221: "old == > e" > >> 2021/11/15 11:54:14 kid1| assertion failed: Transients.cc:221: "old == > e" > >> 2021/11/15 12:16:27 kid1| assertion failed: Transients.cc:221: "old == > e" > > > > I recommend ignoring queue overflows until the above assertions are fixed > because worker deaths cause queue overflows. Your Squid is buggy, and those > bugs essentially cause queue overflows. > > > > The assertion itself is known as Bug 5134: > > https://bugs.squid-cache.org/show_bug.cgi?id=5134 > > > > That bug has a speculative fix (master/v6 commit 5210df4). Please try it > if you can. > > > > > > HTH, > > > > Alex. > > > > > >> -----Original Message----- > >> From: Alex Rousskov [mailto:rouss...@measurement-factory.com] > >> Sent: Friday, November 12, 2021 5:24 PM > >> To: Lou?ansk? Luk??; squid-users@lists.squid-cache.org > >> Subject: Re: [squid-users] Too many ERROR: Collapsed forwarding queue > >> overflow for kid2 at 1024 items > >> > >> On 11/11/21 10:19 AM, Lou?ansk? Luk?? wrote: > >> > >>> recently I'm facing too many ERROR: Collapsed forwarding queue > >>> overflow for kid2 at 1024 items lines in my Squid 5.2 log files. > >> > >> We see those overflows when kids die. Do you see any FATAL messages, > assertions, or similar deadly errors in cache.log? > >> > >> > >>> Could someone elaborate how the queue is filled - what is clogging it? > >> > >> The sender/writer sends messages faster than the recipient/reader is > >> reading them, eventually exceeding the queue capacity (i.e. 1024 > >> messages). These messages are about Store entries that may need > >> synchronization across workers. Each message is very sm > > all. > >> > >> > >>> I don't mind too much if I have to turn collapsed forwarding off > >> > >> Most likely, the problem is not tied to collapsed forwarding. These > >> queues were used for collapsed forwarding when they were added, but > >> they are used for regular traffic as well in modern SMP Squids. We > >> need to change the queue names (and related code/m > > essage text) to reflect the expanded nature of these queues. > >> > >> > >> HTH, > >> > >> Alex. > >> > > > > ------------------------------ > > Message: 3 > Date: Tue, 16 Nov 2021 18:33:30 +0100 > From: David Touzeau <da...@articatech.com> > To: squid-users@lists.squid-cache.org > Subject: Re: [squid-users] Stable Squid Version for production on > Linux > Message-ID: <60b9c5c9-202c-ad3c-c90d-a78f45f6c...@articatech.com> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > Hi, > > For us it is Squid v4.17 > > Le 16/11/2021 ? 17:40, Graminsta a ?crit?: > > > > Hey folks ?;) > > > > What is the most stable squid version for production on Ubuntu 18 or 20? > > > > Marcelo > > > > > > _______________________________________________ > > squid-users mailing list > > squid-users@lists.squid-cache.org > > http://lists.squid-cache.org/listinfo/squid-users > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > < > http://lists.squid-cache.org/pipermail/squid-users/attachments/20211116/5b3 > 1cc34/attachment-0001.htm > <http://lists.squid-cache.org/pipermail/squid-users/attachments/20211116/5b31cc34/attachment-0001.htm> > > > > ------------------------------ > > Message: 4 > Date: Tue, 16 Nov 2021 13:09:12 -0500 > From: Alex Rousskov <rouss...@measurement-factory.com> > To: Lou?ansk? Luk?? <loucansky.lu...@kjj.cz>, Squid Users > <squid-users@lists.squid-cache.org> > Subject: Re: [squid-users] Too many ERROR: Collapsed forwarding queue > overflow for kid2 at 1024 items > Message-ID: > <369d5766-b6ab-f4cd-8cef-64b298d84...@measurement-factory.com> > Content-Type: text/plain; charset=windows-1250 > > On 11/16/21 12:00 PM, Lou?ansk? Luk?? wrote: > > > I will try to backport it from that patch into the v5 tree I've > > downloaded today. As we were using the mentioned build I came across > > these new assertions: > > > 2021/11/16 10:29:46 kid1| assertion failed: StoreMap.cc:241: > "anchorAt(anchorId).reading()" > > 2021/11/16 11:32:51 kid2| assertion failed: Transients.cc:221: "old == e" > > 2021/11/16 14:29:41 kid2| assertion failed: store.cc:1108: "store_status > == STORE_PENDING" > > I hope that at least some of the above assertions are fixed by master/v6 > commit 5210df4. > > > > 2021/11/16 17:40:21 kid1| assertion failed: cbdata.cc:372: "c->locks > 0" > > 2021/11/16 17:40:44 kid1| assertion failed: cbdata.cc:115: "cookie == > ((long)this ^ Cookie)" > > This is probably an unrelated bug. I recommend filing a bug report in Squid > bugzilla and posting the corresponding "bt full" backtrace there. > > > Alex. > > > > -----Original Message----- > > From: Alex Rousskov [mailto:rouss...@measurement-factory.com] > > Sent: Tuesday, November 16, 2021 3:42 PM > > To: Lou?ansk? Luk??; Squid Users > > Subject: Re: [squid-users] Too many ERROR: Collapsed forwarding queue > > overflow for kid2 at 1024 items > > > > On 11/16/21 4:38 AM, Lou?ansk? Luk?? wrote: > >> is it going to be patched only in the v6 version? > > > > I hope the existing fix applies to v5 cleanly, and I am ready to help > with > backporting if it does not. Beyond that, it is in the maintainer hands. I > cannot predict whether or when the fix will be officially merged into v5 > because I do not understand how those decisions are made. > > > > > >> Anyway - in the morning I run debug with 20,9 to see: > >> ... > >> 2021/11/16 09:02:06.496 kid2| assertion failed: Transients.cc:221: "old > == e" > > > > Unfortunately, I cannot see the cause of the assertion in this > short/partial trace -- the problematic actions happened before the trace or > were not logged during the trace. > > > > Patching your Squid with commit 5210df4 is the best next step IMO. If > that > patch does not help, then there are probably other bugs that we need to fix > in v5 (at least). > > > > > > HTH, > > > > Alex. > > > > > >> -----Original Message----- > >> From: Alex Rousskov [mailto:rouss...@measurement-factory.com] > >> Sent: Monday, November 15, 2021 5:17 PM > >> To: Squid Users > >> Cc: Lou?ansk? Luk?? > >> Subject: Re: [squid-users] Too many ERROR: Collapsed forwarding queue > >> overflow for kid2 at 1024 items > >> > >> On 11/15/21 7:43 AM, Lou?ansk? Luk?? wrote: > >> > >>> 2021/11/14 10:13:30 kid2| assertion failed: Transients.cc:221: "old == > e" > >>> 2021/11/15 08:37:36 kid2| assertion failed: Transients.cc:221: "old == > e" > >>> 2021/11/15 11:54:14 kid1| assertion failed: Transients.cc:221: "old == > e" > >>> 2021/11/15 12:16:27 kid1| assertion failed: Transients.cc:221: "old == > e" > >> > >> I recommend ignoring queue overflows until the above assertions are > fixed > because worker deaths cause queue overflows. Your Squid is buggy, and those > bugs essentially cause queue overflows. > >> > >> The assertion itself is known as Bug 5134: > >> https://bugs.squid-cache.org/show_bug.cgi?id=5134 > >> > >> That bug has a speculative fix (master/v6 commit 5210df4). Please try it > if you can. > >> > >> > >> HTH, > >> > >> Alex. > >> > >> > >>> -----Original Message----- > >>> From: Alex Rousskov [mailto:rouss...@measurement-factory.com] > >>> Sent: Friday, November 12, 2021 5:24 PM > >>> To: Lou?ansk? Luk??; squid-users@lists.squid-cache.org > >>> Subject: Re: [squid-users] Too many ERROR: Collapsed forwarding > >>> queue overflow for kid2 at 1024 items > >>> > >>> On 11/11/21 10:19 AM, Lou?ansk? Luk?? wrote: > >>> > >>>> recently I'm facing too many ERROR: Collapsed forwarding queue > >>>> overflow for kid2 at 1024 items lines in my Squid 5.2 log files. > >>> > >>> We see those overflows when kids die. Do you see any FATAL messages, > assertions, or similar deadly errors in cache.log? > >>> > >>> > >>>> Could someone elaborate how the queue is filled - what is clogging it? > >>> > >>> The sender/writer sends messages faster than the recipient/reader is > >>> reading them, eventually exceeding the queue capacity (i.e. 1024 > >>> messages). These messages are about Store entries that may need > >>> synchronization across workers. Each message is very sm > >> all. > >>> > >>> > >>>> I don't mind too much if I have to turn collapsed forwarding off > >>> > >>> Most likely, the problem is not tied to collapsed forwarding. These > >>> queues were used for collapsed forwarding when they were added, but > >>> they are used for regular traffic as well in modern SMP Squids. We > >>> need to change the queue names (and related code/m > >> essage text) to reflect the expanded nature of these queues. > >>> > >>> > >>> HTH, > >>> > >>> Alex. > >>> > > > > ------------------------------ > > Message: 5 > Date: Tue, 16 Nov 2021 13:23:00 -0500 > From: Alex Rousskov <rouss...@measurement-factory.com> > To: squid-users@lists.squid-cache.org > Subject: Re: [squid-users] Multi-clients VPS - Authentication been > shared. > Message-ID: > <7d3ac49b-d2f7-fffa-cb2d-e2377b8ad...@measurement-factory.com> > Content-Type: text/plain; charset=windows-1252 > > On 11/16/21 11:53 AM, Graminsta wrote: > > Hello friends, > > > > ? > > > > I'm using these user authentication lines in squid.conf based on > > user?s authentication list: > > > > ? > > > > auth_param basic program /usr/lib/squid/basic_ncsa_auth > > /etc/squid/users > > > > auth_param basic children 5 > > > > auth_param basic realm Squid proxy-caching web server > > > > auth_param basic credentialsttl 2 hours > > > > auth_param basic casesensitive off > > > > ? > > > > http_access allow localhost > > > > acl clientes proxy_auth REQUIRED > > > > http_access allow clientes > > http_access deny !Safe_ports > > http_access deny CONNECT !SSL_ports > > http_access allow localhost manager > > http_access deny manager > > http_access deny all > > Please note that you are allowing authenticated clients to send traffic to > unsafe ports. For example, they can CONNECT to non-SSL ports. You may want > to reorder the above rules if that is not what you want. > > > > #List of outgoings (all IPs are fake) > > > > http_port 181.111.11.111:4000 name=3 > > acl ip3 myportname 3 > > tcp_outgoing_address 2804:1934:2E1::3D6 ip3 > > > > ? > > > > http_port 181.111.11.112:4001 name=4 > > acl ip4 myportname 4 > > tcp_outgoing_address 2804:1934:3a8::3D7 ip4 > > > > ? > > > > The problem is that everyone whom is in the users file are allow to > > use all tcp_outgoing_address. > > > > If a smarter client scans for open IPs and ports will be able to find > > these outgoings. > > > > ? > > > > How can I restrict each user to their own tcp_outgoing_address output? > > I suspect you are asking the wrong question. A better question is "How do I > restrict each user to their own http_port?". The answer is "Use http_access > to deny authenticated users connected to wrong ports." > > However, you should also ask yourself another question: "Why am I using > multiple http_ports if all I care about is who uses which > tcp_outgoing_address?". The listening ports have virtually nothing to do > with tcp_outgoing_address... > > I suspect you want something like this instead: > > http_port ... > tcp_outgoing_address ...:3D01 user1 > tcp_outgoing_address ...:3D02 user2 > tcp_outgoing_address ...:3D03 user3 > ... > > ...where userN is an ACL that matches an authenticated user N. > > > HTH, > > Alex. > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > squid-users mailing list > squid-users@lists.squid-cache.org > http://lists.squid-cache.org/listinfo/squid-users > > > ------------------------------ > > End of squid-users Digest, Vol 87, Issue 19 > ******************************************* > > _______________________________________________ > squid-users mailing list > squid-users@lists.squid-cache.org > http://lists.squid-cache.org/listinfo/squid-users >
_______________________________________________ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
