This problem only arises in large scale hosting situations where LXC containers host WordPress containers.
There are a variety of solutions + the most simple + highest performance + somewhat self documenting appears as follows…
1) Every LXC container has it’s own IP address. For me, each client owns their own IP address, so if one client engages in hinky-black-hat-esque behavior, then only their sites suffer. Also resource management, especially IOPs tracking + capping is a breeze.
2) Route all protocols (TCP/UDP/ICMP) + all ports from public facing IP to Container IP, for example…
iptables -w -t nat -A PREROUTING -i eth0 –dst 198.50.134.220 -j DNAT –to 10.0.3.54 -m comment –comment ‘lxc-wire-ip faststablehosting.com ‘
3) The route all local traffic targeting the public IP (which routes across lo/127.0.0.1) for a particular back to the correct Container IP, for example…
iptables -w -t nat -A OUTPUT -o lo –src 198.50.134.220 -j DNAT –to 10.0.3.54 -m comment –comment ‘lxc-wire-ip faststablehosting.com ‘
This will allow code like WP Super Cache + Social Engine linkage to work correctly, as this iptables rule correctly handles public IP references from both the host machine + all LXC Containers.
One caveat, there appears to be a bug in iptables which breaks packet routing if the actual interface for a public IP is used, instead of it’s parent interface, which had my pulling my hair out for a good bit.
So if 198.50.134.220 lives on eth0:1 for the first iptables rule to work, eth0 must be used. The eth0:1 interface will be accepted + packets are dropped silently.
I’ve opened an upstream Ubuntu bug ticket to either have this fixed of for iptables to emit an error message + error out, if a child interface is specified, as current behavior is down right ugly.
