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 _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
