Enable client IP address capturing thanks to proxy protocol

[przemek-pokrywka]

When lets-proxy2 runs behind an AWS Elastic Load Balancer then the knowledge about the client IP address is lost (the source IP is set to the ELB's internal address). It's a shame, because knowledge about the client's IP address is often valuable.

As a user of lets-proxy2 I would like this program to support the proxy protocol (mentioned at https://aws.amazon.com/premiumsupport/knowledge-center/elb-capture-client-ip-addresses/ and implemented by various HTTP servers, like nginx) so I could run it behind my AWS ELB and still know the IP addresses of my clients.

[przemek-pokrywka]

Maybe https://github.com/armon/go-proxyproto would be of help.

[rekby]

Hello.

Thanks for descriptions. After fast research - yes, I can add support proxy protocol in lets-proxy.

I have not time for it right now - you can add it by PR:

1. Add config EnableProxyProto bool for enable it only when need: https://github.com/rekby/lets-proxy2/blob/f980fcfa3734a5ec478e0f4723df75f3a795b5d0/internal/tlslistener/config.go#L14
2. Add default false value to default config: https://github.com/rekby/lets-proxy2/blob/f980fcfa3734a5ec478e0f4723df75f3a795b5d0/cmd/static/default-config.toml#L120
3. Replace TCPListeners for ProxyProto listeners only if ProxyProto enabled: https://github.com/rekby/lets-proxy2/blob/f980fcfa3734a5ec478e0f4723df75f3a795b5d0/internal/tlslistener/config.go#L39
4. Add test for check config right apply for true and false value

Or wait when I do it (may 1-2 month).

Then I need help to test it in your environment, because I haven't own L3 load balancers.

[przemek-pokrywka]

Thanks for looking into it and for the guidance. I can't predict when would I have time to handle that, but your remarks provide a good starting point already, thanks.

[przemek-pokrywka]

@rekby I was thinking about the configuration parameters. Does the TCP stream only ever expect to receive the TLS traffic (that is what the name ListenersForHandleTLS name suggests to me)?

If that is the case, then why not to make the proxy support enabled by default (or even hardcoded to be always enabled)?

I think the chance that a valid TLS exchange starts with "PROXY" ( \x50 \x52 \x4F \x58 \x59 ) ASCII bytes is very close to zero if not strictly zero.

What'd be your take on that?

[rekby]

It has TCP listener - for listen HTTP traffic - for proxy it and handle http-01 validation and TLS TCP Listeners - for handle https traffic.

I want it enable in config file explicitly because:

1. It will enable additional proxy level with cpu overhead for all users, even they don't need TCP proxy. Most users don't need the protocol.
2. If it option will enable for public IPs for all incoming traffic - it will open door for easy send request with fake IP in log and backend server. It is security risk (if backend server has some options for white ip list only).
3. If it enable for whitelist ips only - white list must be in config.

[przemek-pokrywka]

Thanks, it makes sense.