[squid-users] Redirect request to cache_peer using username and passwords

Prem Chand premchand142 at gmail.com
Mon Jul 6 15:58:30 UTC 2020


Hi Amos,

On further digging I understood that acl route  via cache_peer_access
(cache_peer_access  Peer1 allow user1)  is not working hence requests are
failing. I'm not sure the exact reason. Can you please suggest how to fix
this?

acl user1 note user username1
cache_peer Peer1 parent 3218 0 round-robin no-query weight=1
connect-fail-limit=1 name=Peer1
cache_peer_access  Peer1 allow user1
cache_peer_access deny all


On Mon, Jul 6, 2020 at 4:00 PM Prem Chand <premchand142 at gmail.com> wrote:

> Hi Amos,
>
> I tried the configuration that you suggested but I'm getting below error.
> It seems the requests are not getting forward to cache_peer. I'm unable to
> figure out what is the cause of the issue. If I revert it to my previous
> configuration I'm not seeing any issue with  cache_peer's.
>
> ** Establish HTTP proxy tunnel to www.google.com:443
> * Proxy auth using Basic with user 'username1'
> > CONNECT www.google.com:443 HTTP/1.1
> > Host: www.google.com:443
> > Proxy-Authorization: Basic bGluZTE6dGVzdGluZw==
> > User-Agent: curl/7.58.0
> > Proxy-Connection: Keep-Alive
> >
> < HTTP/1.1 503 Service Unavailable
> < Server: squid/3.5.27
> < Mime-Version: 1.0
> < Date: Mon, 06 Jul 2020 10:24:28 GMT
> < Content-Type: text/html;charset=utf-8
> < Content-Length: 3905
> < X-Squid-Error: ERR_CANNOT_FORWARD 0
> < Vary: Accept-Language
> < Content-Language: en
> <
> * Received HTTP code 503 from proxy after CONNECT
> * CONNECT phase completed!
> * Closing connection 0
> curl: (56) Received HTTP code 503 from proxy after CONNECT
>
> On Thu, Jul 2, 2020 at 6:29 PM Prem Chand <premchand142 at gmail.com> wrote:
>
>> Hi Amos,
>>
>> Thanks for the response.
>>
>> However, what do you want to happen when that user's dedicated peer is
>> unavailable?
>> Can it be routed to another peer if a dedicated peer is unavailable?
>> because each peer is accessed by a different username and password. If
>> there is an option to route then I will keep a backup peer(Peer4) so if any
>> one of the peers(Peer1,Peer2,Peer3) is unavailable it can route to the
>> backup peer and once the unavailable peer become available then traffic
>> should auto route to them from backup peer.
>>
>> If there is no option that fits as I explained above then I want to stop
>> all access for them.
>>
>> Are you wanting to keep this behaviour?
>> I don't want to use the round-robin behaviour. I want to route requests
>> to dedicated Peer/Client.
>>
>> On Thu, Jul 2, 2020 at 3:19 PM Prem Chand <premchand142 at gmail.com> wrote:
>>
>>>
>>> Hi,
>>>
>>> I need to redirect my clients requests to different Cache_peers using
>>> username and passwords through my proxy. Below is the rough sketch. Can
>>> someone suggest to me how I can achieve this?
>>>
>>> Client1(Username1:password1) ->Proxy:443 -> Cache_peer:3218
>>> Client 2(Username2:password2)->Proxy:443-> Cache_peer:3219
>>> .
>>> .
>>> .
>>> .
>>>
>>> This is my current configuration, I'm doing round robin through
>>> cache_peers when authenticated with a single username and password in
>>> /etc/squid/squidpasswdfile file
>>>
>>> auth_param basic program /usr/lib64/squid/ncsa_auth
>>> /etc/squid/squidpasswdfile
>>> auth_param basic realm proxy
>>> acl auth_users proxy_auth REQUIRED
>>> http_access allow auth_users
>>> http_access deny all
>>> cache_peer Peer1 parent 3218 0 round-robin no-query weight=1
>>> connect-fail-limit=1
>>> cache_peer Peer2 parent 3219 0 round-robin no-query weight=1
>>> connect-fail-limit=1
>>> cache_peer Peer3 parent 3219 0 round-robin no-query weight=1
>>> connect-fail-limit=1
>>>
>>> Thanks & Regards
>>> Premchand.
>>>
>>
>>
>> --
>> prem
>>
>
>
> --
> prem
>


-- 
prem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20200706/524e9be6/attachment.html>


More information about the squid-users mailing list