[squid-users] Squid as Reverse Proxy with Parent Proxy, http inbound and https outbound

[ngtech1ltd at gmail.com]

Hey Joel,
 
I don’t know if squid would be able to do what you want/need but I know that nginx can do some part of what you want.
 
Eliezer
 
----
Eliezer Croitoru
NgTech, Tech Support
Mobile: +972-5-28704261
Email: ngtech1ltd at gmail.com <mailto:ngtech1ltd at gmail.com> 
Web: https://ngtech.co.il/
My-Tube: https://tube.ngtech.co.il/
 
From: squid-users <squid-users-bounces at lists.squid-cache.org> On Behalf Of Joel Howard
Sent: Friday, 12 August 2022 7:28
To: squid-users at lists.squid-cache.org
Subject: Re: [squid-users] Squid as Reverse Proxy with Parent Proxy, http inbound and https outbound
 
Hey Alex,
 
Thanks for the quick and detailed response! I inherited this service recently - would you recommend upgrading to 5? My configs are fairly simple, so upgrade should be easy.
 
Here's my desired flow - let "reverse" and "parent" represent the IPs of those proxies, and "target" represent the target API hostname.

Application sends GET (POST, PUT, etc) http://reverse/some/path
(Note: Application doesn't know target, and couldn't reach it if it did.)

Reverse adds headers to the request
Reverse sends the request to https://target/some/path, using parent as a forward proxy.
 
The parent proxy in my test case accepts TCP, although if possible I would like to support parent TLS proxies as well - this reverse proxy is deployed in different environments where the parent proxy may differ.

I set this up outside of a docker and without trying to force ssl. The config below was my first attempt - it works if the reverse proxy has direct internet access, but just hangs otherwise; my understanding is that requests that use the first cache_peer do not use the second to proxy.
 
# Reverse proxy to google.com <http://google.com> 
http_port 80 accel vhost defaultsite=www.google.com <http://www.google.com> 
cache_peer google.com <http://google.com>  parent 80 0 no-query originserver forceddomain=www.google.com <http://www.google.com>  name=target
request_header_add Joel Joel

# Simplified acl
http_access allow all
cache_peer_access target allow all

# Parent proxy
cache_peer 10.60.4.178 parent 3128 0 no-query default
acl all src 0.0.0.0/0.0.0.0 <http://0.0.0.0/0.0.0.0> 
never_direct allow all

This was my second attempt, using forceddomain to replace the host header but sending the request directly to the parent proxy. This results in the parent receiving GET /, which it does not understand (it expects GET target/somepath).
 
# Reverse proxy directly to forward proxy google.com <http://google.com> 
http_port 80 accel vhost defaultsite=www.google.com <http://www.google.com> 
cache_peer 10.60.4.178 parent 3128 0 no-query originserver forceddomain=www.google.com <http://www.google.com>  name=parent
request_header_add Joel Joel

# Misc
cache deny all
shutdown_lifetime 1 seconds
 
I suspect this would need a url rewriter to force the url to target - I'm failing to get any of the example rewriters working (maybe due to the old squid version?) so I haven't been able to test that yet. But I suspect it will fail for HTTPS, because the rewritten URL will be sent as GET target/something to the parent proxy, instead of CONNECT target/something - I still think I'm missing something to get my squid to use the forward as a proxy while itself functioning in reverse.
 
I'll rewrite these for squid 5 and try to get URL rewriting working. In the meantime, could you let me know if either of these two general approaches is remotely correct and if so, what I can do to get further with them?

Thanks so much! If you happen to be on StackOverflow, I've asked the question with a bounty there <https://stackoverflow.com/questions/73286678/reverse-proxy-with-http-inbound-https-outbound-and-parent-proxy/73293978?noredirect=1#comment129465312_73293978>  as well (although less squid-specific).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20220812/086e038a/attachment-0001.htm>