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