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?
I can't see this ending any way other than "next time I re-locate my stuff to a new server it'll be at a new host with more IPs". Unless you're planning 3-5 years out or your users are real chums, this will probably end in tears.
IPv6 is still not mainstream, without IPv4 you just aren't going to have any visitors. Just having AAAA records will make for a fairly idle server. Anecdotal experience is that in 3-5 years everyone will have junked their cheap wireless router at least once, maybe by the time people buy new ones the cheap routers will support it without needing OpenWRT .
On the security side,
X-Forwarded-For:
was designed for letting servers know what IP connected to the reverse proxy, so you'll need to rewrite the sites' code to have it look at the header rather than the connection itself.SNI was developed to deal with SSL virtual hosts and pretty much every current server supports it, so setting up a reverse proxy from Apache or Nginx should cover you there. If any of the guests needed client-side SSL certs, I don't know how that certificate information is passed on from a proxy (I'm sure it is sent in a header). The real problem here is that on Windows XP, IE does not support SNI and will get the default virtual host's certificate with whatever hostname they entered, hopefully your users will upgrade Windows or switch to Firefox.