RTFM Josh!

One of my latest projects has been to get a VPN link up between my parent’s house and ours, so that I can help them out with computer issues without having to make the trek down to West Chester. Not that I don’t love visiting them (shamless parental plug, they do read this after all), but what with Taylor’s arrival and all we don’t get out much these days. Anyway, after thinking about how best to accomplish this I decided I should use a DD-WRT (open source alternative firmware) flashed Linksys router for the job, for a number of reasons:

  • Thanks to the generousity of a local gentlemen I know from Twitter I acquired one of these devices for free. Don’t ever say Twitter can’t get you stuff!
  • It’s low power and unobtrusive. While I love my big ol’ quad core monster, I didn’t really want to take up space at my parents house.
  • With DD-WRT, it functions great as an OpenVPN client.

Now, the setup was to look something like this:

VPN Diagram

(Please excuse the rather awful drawing, I’m afraid I’m used to Visio)

Once I had everything setup, everything appeared to work, except I couldn’t ping anything at my parent’s end of the tunnel from my home network (vice versa worked fine). Well, normally I might try and sniff the traffic at the two endpoints, but this was a little more complicated than you might think, since the router at my parents doesn’t support such an operation.

In then end, I was able to collect some data after hacking a solution (<geekery>I used an already compiled version of tcpdump and manually moved it to the router</geekry>), and figured out that for some reason the VPN router at my paren’t house was performing what’s known as “masquerading”, or “NATing”. What this means is that any traffic that passed out of it was translated such as to appear that it came directly from the router itself, and not some machine behind it. This novel concept is actually the basis for how pretty much every home router functions; but in this case it was bad, in that it made the tunnel between our networks essentially one way.

So what did I do? Well get royally annoyed of course, proceed to spend the next several hours pouring over the setup of both ends, trying various hacks, googling like crazy, and perhaps questioning my intellect (or that of the programmers of OpenVPN, DD-WRT, and Linux in general) a few times. Finally after giving up for a day, I decided I’d look at a tutorial on the OpenVPN site itself I remembered. It took awhile to find, but there was the answer, right in front of me.

Apparently OpenVPN needs a little special tweaking to allow for traffic from both the “client” (my parent’s house) and “server” (my house) networks to fully talk to each other:

<geekery>

Next, we will deal with the necessary configuration changes on the server side. If the server configuration file does not currently reference a client configuration directory, add one now:

In the above directive, ccd should be the name of a directory which has been pre-created in the default directory where the OpenVPN server daemon runs. On Linux this tends to be /etc/openvpn and on Windows it is usually \Program Files\OpenVPN\config. When a new client connects to the OpenVPN server, the daemon will check this directory for a file which matches the common name of the connecting client. If a matching file is found, it will be read and processed for additional configuration file directives to be applied to the named client.

The next step is to create a file called client2 in the ccd directory. This file should contain the line:

This will tell the OpenVPN server that the 192.168.4.0/24 subnet should be routed to client2.

Next, add the following line to the main server config file (not the ccd/client2 file):

Why the redundant route and iroute statements, you might ask? The reason is that route controls the routing from the kernel to the OpenVPN server (via the TUN interface) while iroute controls the routing from the OpenVPN server to the remote clients. Both are necessary.

Yep, you read correctly. “Both are necessary.” Long story short, I only had one of the two necessary configurations in place. Basically, while the normal

command got the packets as far as the OpenVPN tunnel, the software required that extra

configuration line to correctly send the traffic on its merry way from there. Without it, the traffic would just appear to go out the proper interface, but actually go to that awful place where packets disappear and are never seen again.

</geekery>

Hi everyone, my name is Josh, and yes, I admit it, I should have read the… oh hell you know what the rest means.

Finding Good Candidates For Automation

When resources are tight, folks such as myself in the IT world are often asked to “do more with less”, to use a rather contrite phrase. With layoffs looming for many and already a reality for some, it goes without saying that in the coming year, so-called “knowledge workers” will be asked to stretch their capacity as far as humanly possible. So outside of working insane hours and sacrificing quality time with your family, how do we meet this goal and satisfy our clients?

Now, if you’re reading this blog, chances are you are already a productivity minded person, which puts you at an advantage above those around you. But beyond practicing our GTD skills of constant capture and ruthless review, an ability to single out and automate those routine, time-wasting tasks can prove equally as useful.

As a programmer / business analyst in my previous job (and even now as a product specialist / implementations manager), this mindset was constantly hammered into my way of thinking. There’s a saying that programmers are a lazy bunch, and I certainly won’t deny it; I will however argue that is a good thing. If you’re paying a programmer by the hour, would you rather they spend extra time re-inventing the wheel, or make efficient use of existing code? Similarly, if you’re working with a B.A., wouldn’t you appreciate it if they noticed some repeatable tasks you were paying staff to do that could be easily automated. Granted it’s not always quite that simple, since with automation often comes cost as well. It’s always a give-and-take situation, where the pros and cons must be carefully weighed. If it’s going to take 400 hours and $20,000 to automate a process that takes one person an hour a week to do, that’s probably not a good value.

But really, that’s not what I’m talking about here. The fact is, there are people paid lots of money with fancy initials like “P.M.P” after their name whose job it is to do analysis on larger business processes. No, what I’m suggesting is that you take a closer look at your own daily work, and see if there are any easy targets to be scripted or scheduled, so as to free up your time to take on higher value work. Here’s are three adjectives and phrases that describe good candidates for automation:

  • Repeatable
    You perform the same task on a hourly, daily, weekly, or monthly basis, with very little change. It might be running a report and sending it to a client, doing some number crunching in an Excel sheet, or perhaps pouring over one of those dreadful “green bar” mainframe reports and pulling out some data.
  • Rules Driven
    The task performed is based on hard business rules. For example, you open a report, and if a certain number is off by more than a given percentage, you have to send it to someone.
  • Number Based
    Number crunching, by definition, is highly adaptable to automation. If you spend any amount of time manually punching in calculations or summary statistics, you could probably take care of all the work via something like macros (in MS Office, for example).

How far you go with this is totally up to you. I’m a pretty avid scripting geek, so I’ve been known to write VBScripts, AppleScripts, and even (for you hardcore geeks) bash scripts to do just about anything. Over the next week or so I’ll be looking for good resources on how to script / automate common tasks and tweeting them, so tune in! Here’s a few to get started: