Although I am working with Cloud technology professionally, personally I like to keep my services local. I really like being able to see the servers and disks that are processing and holding my data and I really enjoy setting up the hardware and configuring the operating system and the services running on top.
Hosting services at home isn’t always that easy, though. One thing that usually simplifies things is to have a static IP. Another thing, at least if you want to secure your web servers with SSL certificates, is being able to have multiple IP addresses. Unfortunately I am currently stuck with a provider that offers neither to private customers so I have to make do with just one dynamic IP. Well, necessity is the mother of invention, so read on for the full story of my DMZ setup.
Those who know me will have grown tired of hearing me praising the Raspberry Pi, the credit card sized computer which has has conquered the world. Certainly massively scaled compute intensive task need to have adequately sized hardware, but more services than you would believe will run just fine on this £29.99 (yes, it’s really British!) mini computer.
Storage is an issue though. A Raspberry Pi will by default boot it’s Linux OS from a micro SD card. This is easily fixed though, by adding an external hard disk drive to the Pi and transferring the root file system there (the boot partition still needs to be on the SD card).
For my DMZ setup I opted for the Seagate Backup Plus Slim 2.5 inch external disk drive, which are available up to at least 4 TB at the time of writing this post. They also fit very nicely in my “DMZ shelf” setup so that I can put the HDD just below its respective Pi.
One thing to remember if you’re going this route: You need to tell the Pi to disable the USB port current limiter to give sufficient power to the disks by adding the following line to /config/boot.txt and then rebooting:
So, the hardware basics is in place. What I’ve done is to divide my services onto five different computers to find a balance in memory and CPU usage. I ended up with this setup (Pi 1 in the bottom shelf and counting up):
Pi 1: Mail server (Exim)
Pi 2: Apache and WordPress server for hosted sites
Pi 3: Apache and WordPress server for personal sites, DNS master server.
Pi 4: Asterisk VoIP/SIP server and Jabber/XMPP chat server.
Pi 5: DNS slave server.
At this point you’re probably wondering how these five computers are sharing the measly single IP address. Well, Cloud technology to the rescue! Nowadays it’s quite simple to find reasonably priced VPS (Virtual Private Server) offerings which will include at least one static IP address, and usually with the option of buying additional IPs for a monthly fee.
In my case I’m just using the VPS machine as an “IP frontend”, where traffic destined for a service port on one of its IPs actually is routed towards a corresponding host in my DMZ cluster.
This setup relies on my Ubiquiti EdgeRouter Lite establishing an IPSec tunnel towards the VPS, on top of which I run a GRE tunnel for routing. Routing the traffic from the VPS into the tunnel is simple using iptables DNAT rules such as:
iptables -t nat -A PREROUTING -d <external-ip> -p tcp -m tcp --dport 80 -j DNAT --to-destination <dmz-ip>
For outgoing traffic that needs to be associated with the external VPS IP and not the dynamic IP from my provider, corresponding source routing rules in the edge router and SNAT rules in the VPS will forward the traffic appropriately in the other direction as well:
iptables -t nat -A POSTROUTING -s <dmz-ip> -j SNAT --to-source <external-ip>
The performance of this $90 router is sufficient to run IPSec encapsulated GRE at ~30Mb/s on my 100/100 Mb/s link which is more than enough for my requirements.
So that’s scratching the surface of the DMZ setup – there’s of course lots of details in this. Some things to consider:
- Make sure that your VPS is willing to set reverse lookup (PTR) records for your FQDNs! This is especially important for your mail server – many receiving sites will refuse to handle incoming e-mail originating from a host without a reverse record, or where the reverse record don’t match the A record.
- It’s fully possible to run IPSec with one side having a dynamic IP, but it helps if you are able to push your dynamic IP to your DNS server and let the IPSec config in the other end (StrongSwan in my case for the VPS side) use the FQDN.
- … because you can then have a small monitoring script on the VPS side checking whether the IP of the dynamic side is changing, and in that case restart the tunnel.
The details of setting up a mail server with sufficient spam fighting capabilities and how to organize a well functioning DNS infrastructure is left for another post.
I hope you enjoyed the quick DMZ rundown!