We’re fresh out of IPv4 addresses. Getting hold of a subnet from your average ISP for hosting purposes is increasingly difficult and expensive, even the public cloud providers are getting stingy. While we wait for IPv6 to become usable, there are ways to stretch out the IPv4 space.
There are several big problems with IPv6 that I won’t bother rehashing here, but the real barrier to adoption is that consumer-facing ISPs in many parts of the world still aren’t handing out IPv6 addresses to subscribers. Canada in particular is bad for this.
Even putting aside the inability to get IPv6 addresses directly from the ISPs on consumer lines, getting an IPv6 subnet for use with business fibre connections can often be a nightmare of justification forms and bureaucratic nonsense.
The ISP of one of my clients, for example, wants me to detail the name of each computer that will be attached to a given IPv6 address and what’s used for. I just stare at the spreadsheet like a deer in headlights unsure where to even begin with something like that. I’m not sure that drawing a penis in the spreadsheet cells and sending it backed labelled “my answer makes as much sense as your question” is going to get me what I need.
For the foreseeable future, then, we’ll need to make sure all out web-facing services are visible via IPv4. There are still people who just don’t have IPv6 access, and from the looks of things this is a problem that’s going to persist. So how to we go about taking the few IPv4 addresses we have and making the most out of them?
Reverse proxies
To understand reverse proxies, we should talk a little bit about Network Address Translation (NAT). NAT breaks the end-to-end model obsession that is responsible for most of the horrible things about IPv6. The end-to-end model is the idea that computer A should be able to address computer B with no translation layers in between. The IP address of each computer should be publicly routable and communication interfered with as little as possible.
NAT is the opposite of that. NAT is a fantastic means of plopping an entire network down behind a single IP address and making individual servers behind that IP available on different ports. Instead of offering up RDP access to a computer on the default port of 3389, for example, you might set it to 31826, causing the end user the overwhelming burden of typing out rdp.example.com:31826 instead of rdp.example.com when connecting.
Developers coding applications to live behind NAT have to think a little bit about what might live between the two computers and then use the same techniques and libraries everyone else has used for the past 20 years to make things behind NAT work. I’m told it’s ruinously awful.
If IPv6 purists hate NAT I can only imagine what they think of reverse proxies, but reverse proxies are the future. A reverse proxy accepts all traffic for a given service on a given IP address, figures out which back-end server should serve the request and the routes the traffic. These are most common with HTTP and HTTPS traffic.
HTTP and HTTPS traffic contain a host header (Server Name Indication (SNI) for HTTPS). The host header contains the information about which server you want to access. Instead of simply asking a web server for the website at its IP address, you would specifically ask for www.example.com. Web traffic reverse proxies look at the host header, compare it to their configurations and pass the traffic back to a back-end server.
Web traffic reverse proxies typically also do caching of static content so as to speed up those back-end servers. Increasingly they’re also used for denial of service detection, content inspection or – and this is my favourite – providing an SSL frontend to a whole mess of individual sites that don’t do SSL natively. Those backend websites can be running any web server; if they deliver traffic over HTTP, we can reverse-proxy them with nginx.
Commercial reverse proxy software does, of course, also exist. Citrix NetScaler VPX can act as one, as can Barracuda NG Firewall, Smoothwall UTM and Untangle. There are many, many more, and many exist for services other than HTTP. But let’s nginx – free, open source and very, very widespread.
A practical example
Reverse proxies seem daunting, but they aren’t quite so terrible to implement as might be imagined. It took me a couple of days of fussing to get a CentOS 7 reverse proxy set up, and here’s the basics. (Please note I’m presuming a base level of proficiency with RHEL-based Linuxes that includes installing, logging in and using both vim and yum.)