The Yak Came Back

TL;WR

Hosting a Windows Remote Desktop in your home over the Internet is a risky business, particularly in this era of botnets and ransomware. My father used to invite other volunteers from church into his desktop to help with the books, and I finally convinced him to transition off his PC and into various commercial platforms. Each of those platforms had their pros and cons.

Years have passed, and now I think I can bring the service partway back. Even better, this solution opens the door to some affordable experimentation mixing cloud-hosted and self-hosted services.

And all it required was a little gateway in the cloud with a static IP, another little server at home, a fast home Internet connection, several years of experience, a little guacamole 🔗 , and a patient yak.

Introducing the Yak

According to the Urban Dictionary 🔗 , the top definition of yak shaving is: “Any seemingly pointless activity which is actually necessary to solve a problem … which solves a problem … which, several levels of recursion later, solves the real problem you’re working on."

The term comes from the world's best example of a time sink 🔗 , that starts with a guy wanting to wax his car, and to get that done he follows a series of decisions that ultimately drag him into shaving a yak.

For me that yak was a rented server in Montreal, and the metaphorical unwaxed car was granting access to a Windows program on some Internet accessible desktop. Getting there looked like this:

• Dad needs to share his home desktop for the church, but
• Lisa finds it too slow over Dad’s residential DSL, so
• we need to rent a Windows virtual server, but
• nobody protects the RDP port for the right price in Canada, so
• I can make good use of a rented physical server hosting a few VMs, right?

Uh, yeah, but just because you can doesn’t mean you should. Then again, it was a great place to learn things. Just pay heed to the yak hair warning at the end of this post. People come to rely on your bad ideas, particularly if they accidentally work.

So the rented server was quite the yak to shave, and it takes a long time to unshave a yak. Sad but true: I’m pretty sure my father asked about desktop sharing back in 2002 or so. That means that this evolving solution is old enough to vote in most countries. Here’s the good news: in that time residential Internet got fast, the cloud got cheap, and I learned a bunch of hard lessons.

I think I have a solution with less yak hair in it. Some of its ideas make it possible to host interesting coding projects and then gradually scale them out to bigger equipment if/when they can pay their own way.

Validated Solution, Now with less Yak Hair

Figure 1 is comprised of three layers. Internet routing and naming, an intelligent gateway, and Hollywood-hosted applications.

Internet Routing

At the top layer, all the static parts of my site are directed to AWS S3 (not shown). Each of the moving parts of the site (e,g, web hooks, CI/CD tools, and API proxies) I name with their own CNAME in Cloudflare. Using a CNAME makes it easy to setup, but for rapid redirection you need an intelligent gateway.

Gateway and Connection Broker

The middle layer provides intelligent routing for upstream services. In this example I’m using only a single host, but being almost completely stateless it could be made highly available with only a moderate level of fuss. In this simple form it can be hosted nearly anywhere, preferably somewhere you can easily get a static IP (e.g. AWS or DigitalOcean). If you’re okay with the occasional downtime you can provision the whole thing with an Ansible script in a blink.

This middle layer has three ports open:

Still on the middle layer, I’ve used Traefik in this example but it could be nearly anything (e.g. Kong or HAProxy). It helps to have some kind of discovery capability, even in a single host. Traefik makes that a breeze, and like other tools in this space makes it trivial to enable automatic LetsEncrypt registration for end-to-end TLS.

The other key to this is the Connection Broker, which is a little custom docker image with Nginx configured to proxy upstream HTTP applications and the SSH daemon that receives the Hollywood-hosted connections from the lowest layer.

Hollywood-Hosted Applications

I’m calling this idea “Hollywood Hosting”, a practice I didn’t invent (see ngrok 🔗 and localtunnel 🔗 for a couple of examples), but I’m hoping to get credit for naming the practice. I could use those services, and I do recommend them for a ton of use cases, but I wanted to expand on the basic idea so I built my own.

The security trick is something akin to the Hollywood principle of “don’t call us, we’ll call you”, but only for establishing the availability of a bound server port. The host (my developer box) knows about systems and applications in the home network, including some that are in a completely unreachable network in VirtualBox. This whole network is normally completely unreachable from the Internet (“don’t call us”), but as soon as we SSH up to the middle tier in the cloud on port 2222 (“we’ll call you”), we can tie into a reverse tunnel back to running service we want to host.

These services include whatever you need (e.g. your latest demo of server software), but this particular story called for a Windows desktop, so that’s what you get. I’m running an awesome little docker image called oznu/guacamole 🔗 on my main Linux developer box at home, where I’ve created a VirtualBox VM with a Windows guest to do this proof-of-concept.

VirtualBox is presenting a remote display for the Windows VM to the host network, and I use the reverse SSH tunnel to present Guacamole’s HTTP port to my middle tier.

As you can see from the screenshots below, I can now reach a demo church VM in a browser (the real one is still on my yak server, pending a conversation with the folks at church).

In figure 2 you see the choice of Ubuntu or Church VM in a browser window. I am accessing Guacamole’s desktop chooser interface over the Internet from outside the home.

Note: I have redacted the URL and username to reduce the likelihood of enthusiastic plunder. I now see hosting a virtual Windows Desktop on a virtual network as something of a canary in the coalmine of Internet dangers. It’s like a living thing, and if that canary dies (gets hacked) its sacrifice will have meaning if we live well afterwards.

In figure 3 you see the Windows VM I intend to offer the church access to in a pilot test. The performance was quick enough to play YouTube videos; the videos were explaining the underlying screen sharing application called Apache Guacamole 🔗 .

Solution Summary

As I’ve mentioned in other posts, I tend to provide ideas in broad strokes and avoid depriving you of your own hard-fought victories (see Tygers post for my rationale). If you’d like more details on how this is achieved, please leave a comment.

Previous iterations

You can skip this section if nostalgia isn’t your thing, but for me it shows how far the Internet has come in twenty years.

Such projects always starts with somebody (in this case my father, back around Y2K) asking a simple question like, “Can I invite people to access my desktop without my having to be there?” I love my Dad, and so my impulse was to say yes. A word to the wise: if you ever find yourself in his shoes, asking an IT person that question, you probably shouldn’t start with “Can I …", but rather “Is it safe to …."

Phase IV Note

I decided in 2012 that I had good enough reasons as a coder, sysadmin, and all ‘round propeller-head, there was value in renting some dedicated servers at OVH 🔗 and learning what it means to manage a little server farm in my spare time. In Phase IV that was a single Proxmox server holding a number of LXC containers and one fully virtualized Windows VM for the church. I wanted to block direct access to the Windows VM’s Remote Destop Protocol (RDP) port, so I configured a containerized OpenVPN service and put the Windows machine on a private internal network.

Phase V Note

Proxmox wasn’t my cup of tea (I’m a little too DIY), and so I went pure Linux and KVM. On the security front, I discovered one day when visiting my parents that my father’s PC could see the home printers of another church member. That week I dropped OpenVPN in favour of SSH accessed via public-key cryptography.

Yak Hair Warning

Here’s an architectural tip for you budding system builders out there who want to learn DIY hosting: don’t put a bunch of different VMs on a single server and use it for hosting a dozen different use cases (e.g. host a CI/CD server … and bunch of websites … and a Windows desktop … for other people). For one thing, that server and you (you yak shaving car waxer) are massive single points of failure. If you get hit by a bus (or get a decent job that keeps you from helping in a timely manner), you can expect your name to be uttered in close proximity to words that cannot be repeated here.

Mitigation strategies include retaining control of every bit of the routing in front of all those connections, seeking redundant standby systems, automating the provisioning and software deployment, etc.

Should you fail to heed this warning and instead invite a bunch of users to your multi-faceted server like it’s a Saturday block party, just know you’ll be untangling yak hair for years.