Hi.
Thanks for testing and feedback.
On 2024-06-12 (Mi.) 20:35, Dave Cottlehuber wrote:
On Wed, 12 Jun 2024, at 13:04, Aleksandar Lazic wrote:
Hi.
Attached a new version with updated upstream-proxy.cfg.
This Patch have also the feature `upstream-proxy-target` to get rid of the
dependency for the srv->hostname.
```
tcp-request content upstream-proxy-target www.test1.com
```
Now have I tested the setup with `0.0.0.0` as server.
```
server https_Via_Proxy1 0.0.0.0:0 upstream-proxy-tunnel 127.0.0.1:3128
init-addr
127.0.0.1
```
@Dave: Can you use a name for the upstream-proxy-tunnel instead of IP?
Yes, it does the DNS lookup happily, and I can pass secret via env. nice!
That's great :-)
----------- 8< -----------
frontend stream_fe
bind :::443 v4v6
mode tcp
option tcplog
default_backend stream_be
backend stream_be
mode tcp
tcp-request content upstream-proxy-header Host www.httpbin.org
tcp-request content upstream-proxy-header "$AUTH" "$TOKEN"
tcp-request content upstream-proxy-header Proxy-Connection Keep-Alive
tcp-request content upstream-proxy-target www.httpbin.org
server stream www.httpbin.org:443 upstream-proxy-tunnel "$PROXY":10000
----------- 8< -----------
So this looks good, we send the right headers now thank-you!
Upstream proxy replies "HTTP/1.1 200 OK" which seems legit.
But then haproxy sends RST, instead of the buffered proxy data.
After a a bit more tcpdump & code reading, I made a small
modification in conn_recv_upstream_proxy_tunnel_response/2
struct ist upstream_proxy_successful = ist("HTTP/1.1 200 OK");
and then I get actual data back through the proxy - great!
This seems ok according to
https://datatracker.ietf.org/doc/html/rfc9110#name-connect
"Any 2xx (Successful) response indicates that the sender (and all inbound proxies)
will switch to tunnel mode immediately after the response header section ..."
Is it possible to read up to "HTTP/1.1 200" and then ignore everything
up do 0x0d0a ? that should cover the RFC and both our examples.
That's a good point I will change the check if the connection was successful.
For me, there are still 2 things I'm not clear on:
- I don't follow yet what upstream-proxy-target provides yet, or is this just
plumbing for later when we have requests?
Well Problem is that there must be an option to tell the upstream proxy what's
the target host is. This could be done via "server->hostname" which is in the
case above "www.httpbin.org:443".
When there are several targets host based on sni and there is a map can't the
server name be used here is the solution the "0.0.0.0" and the
"upstream-proxy-target" to solve the issue.
The final idea is something like this.
```
tcp-request content upstream-proxy-header Host %[req.ssl_sni,lower]
tcp-request content upstream-proxy-header "$AUTH" "$TOKEN"
tcp-request content upstream-proxy-header Proxy-Connection Keep-Alive
tcp-request content upstream-proxy-target %[req.ssl_sni,lower]
server stream 0.0.0.0:0 upstream-proxy-tunnel
%[req.ssl_sni,lower,map_str(targets.map)]
```
The targets.map should have something like this.
#dest proxy
sni01 proxy01
sni02 proxy02
I hope the background of upstream-proxy-target is now more clear.
- In `server https_Via_Proxy1 0.0.0.0:0 upstream-proxy-tunnel 127.0.0.1:3128`
from your config, what is 0.0.0.0:0 used for here? This binds to all IPv4
but on a random free port?
This is required when the destination should be dynamic, it's documented here.
http://docs.haproxy.org/3.0/configuration.html#4.4-do-resolve
A+
Dave
Regards
Alex
