Performance of the proxy device compared to traditional iptables rules


(Benoit St André) #1

Hello there!

Do you think there is any performance drawback using the proxy device to forward traffic from the host to an lxc web server instead of using traditional iptables rules ?

Thanks!


Forward port 80 and 443 from WAN to container
#2

This would be interesting to investigate.

If you can make an installation of both, then you can run ab (from apache2-utils) to benchmark the two.
The -n option in ab is about the number of requests. The -c option says how many requests to make concurrently.


(Benoit St André) #3

Had to remove the proxy rules and put iptables rules because I discovered that nginx was always seeing 127.0.0.1 as the IP doing the request instead of the original ip (because of my connect=tcp:127.0.0.1:443 in the proxy device definition I suppose.

Could the proxy not rewrite the IP?


#4

That’s a common issue when you use a proxy. The solution is also common. In the case of nginx, you would use this module, http://nginx.org/en/docs/http/ngx_http_realip_module.html to restore the source IP address. nginx would rewrite the source IP from the Host: HTTP header.

Most likely, you will end up using HAProxy so that you can put many more websites in different LXD containers. In that case, you need to tinker HAProxy according to https://www.haproxy.com/documentation/aloha/9-5/traffic-management/lb-layer7/http-rewrite/


#5

Is there a way for LXD’s proxy device to add the X-Forwarded-For header to the requests?


#6

LXD’s proxy device works on the TCP/IP transport layer. This means that it does not know about HTTP and other higher level protocols. That is, it’s much more generic/usable than a specific protocol like HTTP.
In addition, LXD’s proxy device can proxy any of TCP, UDP and UnixSockets, in any combination.

Therefore, it’s not possible to add a header like X-Forwarded-For because that header is specific just to HTTP.

This has been a big issue with proxy servers, and the haproxy team created the proxy protocol. With the proxy protocol, the proxy adds a specific information at the start of the connection that says what’s the originating IP address. Then, the receiving software must understand this proxy protocol, read this information and remove it. Then, the rest of the connection continues as normal.

In LXD, you add the proxy_protocol flag to the proxy device in order to activate the proxy protocol. Then, you also need to enable support for proxy protocol in haproxy, nginx, apache, etc. By doing so, these services manage to get the proper originating IP address.


#7

Thank you for the detailed explanation. I learned something new today!


#8

I thought it would be interesting to share: I’m currently uploading stuff to a Nextcloud instance in a container at a few dozens of megabits per second.

The stack is : LXD Proxy - Caddy (for TLS) - Nginx - PHP-FPM/MariaDB/Redis

It’s interesting to see that the LXD proxy is visible as actual processes, though it seems to use quite a lot of CPU?


(Stéphane Graber) #9

That is quite a lot of CPU being used, if it’s actively relaying a lot of data, that may be normal, though if you’re expecting your system to be mostly idle request wise, then there may be a bug in there.

Might be worth using tcpdump to see just how much traffic is headed towards the proxied port and if close to none can be found, then something is likely off and a dump of the proxy process with strace may be useful.