My hoster is - understandably - cutting down on IPv4 addresses offered with new servers so that the next time I re-locate my stuff to a new server I'll a huge number of IPv6 addresses, but only a single IPv4 address.
For the services of which I run only one instance (such as SMTP) this shouldn't be an issue. I'll simply NAT the stuff through (using iptables/6
). However, for other services - and I'm in particular worried about HTTP/S here - I see the issue of how to pass incoming traffic to the correct guest machine and obviously getting the outbound data en tour to the client again.
My main issue here is security. I think I could (ab)use one of the usual proxies or a web server (nginx, lighttpd) that can also serve as a proxy. However, in this case the guest systems see this as a "local request" and certain access control mechanisms may fail. Also, HTTPS is a big issue here because of the encrypted traffic, though I could have the host system implement the HTTPS parts entirely and proxy from/to guest systems unencrypted (have been using that method on a single machine where a lighttpd instance served as the frontend to an Apache2 backend handling a particular set of URIs).
How can I offer the same service (HTTP/S here) to the outside world even though the handling of individual domains is performed by individual guests? Or rather what's considered best practice these days?
[internet] <--> [IPv4:host] <-+-> [guest:foo.org]
|
|-> [guest:bar.org]
|
|-> [guest:baz.org]
... or can I perhaps disregard all these problems by only giving AAAA
records to those domains and letting the client-side handle everything?