[squid-users] Reverse proxy and TUNNEL to same cache peer

[Amos Jeffries]

On 08/08/18 01:04, Hariharan Sethuraman wrote:
> Hi,
> 
> We have our company proxy and this is how the topology is expected to
> look like for the deployment:
> 
> Client
> -------------------squid-host.com---------------------------company-proxy------------Internet
> 
> Now I need to allow reverse proxy(3128) for some request from the client
> and tunnel (3129) as well.

This reads like you don't understand what either of those terms mean.

Your proxies port 3129 is setup for forward-proxy traffic.

"tunnel" is and action that can be done by clients. Also the term used
to describe the *payload* of a CONNECT message. The action a
forward-proxy performs when receiving a CONNECT is usually to setup a
tunnel CONNECT-ion for non-HTTP use.

Using port 3128 for reverse-proxy traffic is a very bad idea. That port
is a well-known port and also reserved for explicit / forward-proxy traffic.


> 
> Configuration:
> http_port 3128 accel allow-direct
> http_port 3129
> never_direct allow all
> always_direct deny all
> ...
> cache_peer company-proxy parent 80       0  no-query no-digest
> login=PASS originserver
> url_rewrite_access allow all
> url_rewrite_program  /usr/bin/python ./rewriter_program.py
> 
> Usecases:
> 
> 1) Reverse proxy: Now I can successfully get the response for the query
> like curl -X GET http://squid-host.com:3128/microsoftapi/api/something.
> Basically I rewrite URL to https://microsft.com/api/something and
> through company-proxy I get the response successfully from e.g.,
> microsoft.com <http://microsoft.com>.

Re-writing message URLs across the insecure / secure boundary is a very
bad idea. All Cookies and other things in both message headers and
payload content which are tied to either the TLS or the Origin state
will be broken.

The client thinks it is talking to an insecure server, and the server
thinks it is connected to a secure client. They also have very different
ideas about the Origin scope for stateful security things - especially
when re-writing across domains like this. That means they each believe
different range of actions are valid, and that impacts on what they
expect the other agents behaviour to be in reaction to any given message.


> 
> 2) Tunnel: It fails when the client do a query like curl -x
> http://squid-host.com:3129 -X GET https://googlecloudapis.com/api/something
> < HTTP/1.1 503 Service Unavailable
> < Server: squid/3.5.20
> < Mime-Version: 1.0
> < Date: Tue, 07 Aug 2018 12:36:07 GMT
> < Content-Type: text/html;charset=utf-8
> < Content-Length: 3879
> < X-Squid-Error: ERR_CANNOT_FORWARD 0
> < Vary: Accept-Language
> < Content-Language: en
> <
> * The requested URL returned error: 503
> * CONNECT phase completed!
> * Connection #0 to host squidhostname.com <http://squidhostname.com>
> left intact
> Now, if I remove the origin server, the TUNNEL goes through and getting
> the response but the reverse proxy fails.
> 

Please add the --verbose option to your curl test commands to see what
is actually being sent to the proxy. Then test what your re-writer is
causing to happen on those received URI.

Note that all the re-writer does is change the URI. It does not change
the method or other request details. If it produces an invalid or
unreachable URI there is nothing Squid can do but present the client
with an error.



> Could you let me know how I can handle both tunneling and reverse proxy
> through same cache peer?

Both are already supported and work without any fancy setup. I think you
are hitting something else which should become clearer when you see what
curl is actually doing.

Amos