2.0 new option: do-resolve problems

Help!
1 
frontend fe
    bind 10.0.0.1:3128 transparent
    mode tcp
    tcp-request content do-resolve(txn.myip,mydns,ipv4) req.hdr(host),lower
    default_backend be

backend be
    tcp-request content reject if { var(txn.myip) -m ip 127.0.0.0/8 10.0.0.0/8 }
    tcp-request content set-dst var(txn.myip)
    server clear 0.0.0.0:0

Here are 2 problems:

  1. if ipv6 is prefered instead ipv4, in backend 0.0.0.0:0 cannot handle this case.
  2. Because var(txn.myip) is randomly selected, is it still possible to use “source IP affinity” to keep session persistent? E.g. client 10.0.0.2 connects to example.com(IP1,IP2,IP3). Within 2.0.3 version, all 3 IPs would be load-balanced, but in fact only one of them should be picked up.
2

You are trying to do something that haproxy is not build for. haproxy is not a forward proxy, you’d by spending a lot of time figuring out a working configuration which in the end would be discouraged and unsupported.

I suggest you look for a real forward proxy instead. Take a look at tinyproxy for example.

3

Thanks for your remind. In terms of CPU/RAM efficiency, Haproxy outperforms a lot. Let alone versatile combinations of frontends and backends. Even if it binded to 10.0.0.1:80/443, sessions persistence with backends would still be concerned. E.g. All 3IPs servers the same HTTP video streamings, while different keys are provisioned to deciper contents for each session. Hence I suppose they will not be corner cases sometimes.

4

Sessions persistence works per server, it’s impossibile for it to work if the servers are not configured. This will never work and haproxy is not designed for this.

5

OK, I see. :sweat_smile: Haproxy will not hash/stick variable destinations, the same as NGINX.

6

Please forgive me. I still cannot understand the problem 1, i.e. access from IPV4 to IPV6. In my opinion, “0.0.0.0:0” won’t be able to deal with IPV6.

7

Yes, I doubt set-dst can handle both address families. I suggest you file a bug on github.