Working from Home

Since I've radically changed my work VM configuration, I needed to change my home PC in order to connect properly to the new setup.

Before we dive in, a brief review of the old setup: the host at work, which we will call `audia`, ran a VirtualBox guest named `dev`.  dev had its own set of configs and configuration knobs so that I could write 127.0.0.1 dev.audia.pc dev into /etc/hosts, point Firefox to dev:10080, and code running on dev would be able to recognize "this is development," not require TLS, and know that http://dev:10080/ is the URI root of the app.  I configured VirtualBox's port forwarding to listen on 0.0.0.0 from audia, and when I connected to the VPN, my home computer (call it `starlet`) had its own /etc/hosts listing that used the internal IP of audia for dev.  The same URI from home would then get connected via port-forwarding to the dev VM.

This all changed when I wanted to test a SAN certificate and some redirection rules.  I didn't want certificate mismatch errors in Firefox, and I needed dev to think it was the production server so that it would use the production ruleset.  That became the underlying justification for devproxy.  After that point, dev had the production certificates, hostnames, and rules.  It had a host-only network added, which audia now used, and I took out the port forward.  (This was the problem behind getting Lost in the Complexity.)

But without the port forward, starlet can't reach dev anymore, only audia.  Of course, I came up with a solution:

(Despite what may be implied, the VPN isn't connected to starlet.  I just didn't feel like redrawing the whole tube.)



Some of the neat toys that make this work are POSIX-only and starlet is Win64, so the first thing is the introduction of `ninja`: a Linux VirtualBox guest.  This guest connects to the VPN, and as before, can now connect directly to audia.  As a convenient bonus, with the VPN connected from the guest VM, Windows doesn't see a need to disconnect it when switching users.

But since it's POSIX, it can use sshuttle to log into audia... and forward traffic destined for dev's host-only network over to audia for routing.  That's the 192.168.56.0/24 network: VirtualBox's default host-only address space.  (ninja is also on a host-only network so I can easily connect from starlet; the host-only network on this machine is given a non-default numbering so it doesn't conflict.)

Now anything running on ninja, such as devproxy, can connect directly to dev without any further trouble.  (Of course, dev is listed by its 192.168 IP in ninja's /etc/hosts.)  Since I gave ninja a host-only network as well, FoxyProxy can be configured to connect to it, and complete the circuit.

Also since ninja is POSIX, I can use mosh to log into audia to cut down on the latency issues due to routing three states over and back (work and home have different ISPs, and the home ISP routes everything three states over.)  mosh can't log in directly to dev, because sshuttle doesn't use the normal routing table and the UDP packets intended for ninja don't go anywhere.  But using mosh over the slow network and then ssh to the local-from-there guest VM isn't bad.

Sometimes I worry that I'm building overly-complex things.  Then I remember what has come before and it doesn't look so bad.