Neologism: Cave diving

Apr 22 2020

cave diving - noun phrase - The act of tunneling through multiple VPNs, bastion hosts, and chokepoints to access some network assets, usually production infrastructure in a more restricted network.  Less hazardous than but just as easy to screw up as real life cave diving.

Tunneling across networks with Nebula.

Apr 12 2020

Longtime readers have no doubt observed that I plug a lot weird shit into my exocortex - from bookmark managers to card catalogues to just about anything that has an API.  Sometimes this is fairly straightforward; if it's on the public Net I can get to it (processing that data is a separate issue, of course).  But what about the stuff I have around the lab?  I'm always messing with new toys that are network connected and occasionally useful.  The question is, how do I get it out of the lab and out to my exocortex?  Sometimes I write bots to do that for me, but that can be kind of clunky because a lot of stuff doesn't necessarily need user interaction.  I could always poke some holes in my firewall, lock them to a specific IP address, and set static addresses on my gadgets.  However, out of necessity I've got several layers of firewalls at home and making chains of port forwards work is a huge pain in the ass.  I don't recommend it.  "So, why not a VPN?" you're probably asking.

I'd been considering VPNs as a solution.  For a while I considered the possibility of setting up OpenVPN on a few of my devices-that-are-actually-computers and connecting them to my exocortex as a VPN concentrator.  However, I kept running into problems with trying to make just a single network port available over an OpenVPN connection.  I never managed to figure it out.  Then part of me stumbled across a package called Nebula, originally developed by Slack for doing just what I wanted to do: Make one port inside available to another server in a secure way.  Plus, at the same time it networks all of the servers its running on together.  Here's how I set it up.

OpenVPN, easy configuration, and that damned ta.key file.

Apr 15 2017

Now that ISPs not selling information about what you do and what you browse on the Net is pretty much gone, a lot of people are looking into using VPNs - virtual private networks - to add a layer of protection to their everyday activities.  Most of the time there are two big use cases for VPNs: Needing to use them for work, and using them to gain access to Netflix content that isn't licensed where you live.  Now they may as well be a part of everyday carry.

So: Brass tacks.  Here's a quick way to set up your own VPN server, as well as a solution to a problem that frustrated me until very recently.  For starters, unless you're an experienced sysadmin don't try to freestyle the setup.  There is an excellent script on Github called openvpn-install that will do all of the work for you (including adding and deleting users) in less than a minute.  Use it to do the work for you.  Please.  Also, if you build an OpenVPN server, consider going in with a couple of friends on the cost.

Chances are you're running either Windows or Mac OSX (Linux and BSD users, you know what to do) so you'll need an OpenVPN client on the users' end.  This means that you want to run either the Windows version of the OpenVPN client or an OSX client like Tunnelblick.  However, these clients assume that you're just loading an all-in-one configuration file, called an .ovpn file.  If you've never done it before they're remarkably tricky to build but they're basically a copy of the OpenVPN client.conf with all of the crypto keys embedded in special stanzas.  It took me a lot of fumbling and searching but I eventually figured out how to reliably make them.  To save you some time here's a copy of the one I use with all the unique stuff removed from it.  If you open it in a text editor you'll notice a couple of things: First, the very first non-commented line says that it's for the client and not the server.  Second, I have it configured to use TCP and not UDP.  This is so that you don't have to reconfigure the firewall you're behind to get your traffic through.  Keep it simple, trust me on this.  Third, the ca, cert, and key directives are commented out because those keys are embedded at the end of the file.  Fourth, I have tls-auth enabled so that all traffic your server will handle is authenticated for better security.

If you freestyle (that is, build by hand) your OpenVPN server, you'll need to keep in mind the following things: