[squid-users] Multi-clients VPS - Authentication been shared.
Alex Rousskov
rousskov at measurement-factory.com
Fri Nov 19 16:06:39 UTC 2021
On 11/18/21 3:54 PM, Graminsta wrote:
> 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.
This statement does not explain why you need multiple http_ports.
> I have several customers per VPS.
> Each one uses like 10 different ports to direct connections through
> different IPv6s.
These statements may conceal the answer, but I still do not understand
why all your customers cannot use one IPv6 http_port. Please note that I
am not saying that they can. I am only saying that it is not clear (to
me) why you cannot simplify this configuration to one http_port.
> 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?
For each port X, you need to define an ACL that matches users that are
allowed to use http_port X. I do not know how to do that exactly because
I do not know what rules you use to make that decision -- these rules
are specific to your business/application logic. Once you have that ACL,
you only allow to-port-X traffic that matches it. Here is a sketch:
http_port ... name=X
http_port ... name=Y
...
acl toPortX myportname X
acl toPortX myportname Y
...
acl allowedToUsePortX ...
acl allowedToUsePortY ...
...
http_access ... "standard" safety/admin rules here ...
http_access allow toPortX allowedToUsePortX
http_access allow toPortY allowedToUsePortY
...
http_access deny all
HTH,
Alex.
> -----Mensagem original-----
> De: squid-users [mailto:squid-users-bounces at lists.squid-cache.org] Em nome
> de squid-users-request at lists.squid-cache.org
> Enviada em: terça-feira, 16 de novembro de 2021 15:23
> Para: squid-users at lists.squid-cache.org
> Assunto: squid-users Digest, Vol 87, Issue 19
>
> Send squid-users mailing list submissions to
> squid-users at 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-request at lists.squid-cache.org
>
> You can reach the person managing the list at
> squid-users-owner at 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" <marcelorodrigo at graminsta.com.br>
> To: <squid-users at 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>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 16 Nov 2021 18:00:56 +0100
> From: Lou?ansk? Luk?? <Loucansky.Lukas at kjj.cz>
> To: "Alex Rousskov" <rousskov at measurement-factory.com>, "Squid Users"
> <squid-users at lists.squid-cache.org>
> Subject: Re: [squid-users] Too many ERROR: Collapsed forwarding queue
> overflow for kid2 at 1024 items
> Message-ID:
> <72DD5D5CF661B5459DC08A060BF26B53010897A8 at 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:rousskov at 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:rousskov at 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:rousskov at measurement-factory.com]
>>> Sent: Friday, November 12, 2021 5:24 PM
>>> To: Lou?ansk? Luk??; squid-users at 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 <david at articatech.com>
> To: squid-users at lists.squid-cache.org
> Subject: Re: [squid-users] Stable Squid Version for production on
> Linux
> Message-ID: <60b9c5c9-202c-ad3c-c90d-a78f45f6c89c at 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 at 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>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 16 Nov 2021 13:09:12 -0500
> From: Alex Rousskov <rousskov at measurement-factory.com>
> To: Lou?ansk? Luk?? <Loucansky.Lukas at kjj.cz>, Squid Users
> <squid-users at 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-64b298d84638 at 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:rousskov at 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:rousskov at 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:rousskov at measurement-factory.com]
>>>> Sent: Friday, November 12, 2021 5:24 PM
>>>> To: Lou?ansk? Luk??; squid-users at 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 <rousskov at measurement-factory.com>
> To: squid-users at lists.squid-cache.org
> Subject: Re: [squid-users] Multi-clients VPS - Authentication been
> shared.
> Message-ID:
> <7d3ac49b-d2f7-fffa-cb2d-e2377b8ada5e at 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 at 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 at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users
>
More information about the squid-users
mailing list