Back in the halcyon days of the dot-com era, I was the first employee at a P2P software startup. Because we were building an intranet and development environment from the ground up, we were free to use Linux everywhere. As everyone now knows, the world changed, and the dot-coms went the way of the dodo. So too did the independence of my little startup, which was acquired by a larger company with an established Windows developer base. Although the new firm was liberal enough to allow me to continue developing on and for Linux, I largely was left to fend for myself on system administration tasks.
The only area where I encountered significant difficulty was with VPN setup. At my old job, every developer had an inbound SSH port mapped to her development workstation. Not only did the new office lock down external access to SSH ports, the sanctioned VPN solution was not Linux-friendly. Technical inertia guaranteed that a cross-platform solution such as FreeS/WAN would not be available in the foreseeable future. Fortunately, VTun, the VPN solution I used at my old job, is flexible enough to handle even this inhospitable environment.
VTun works by seamlessly integrating IP-tunneling technology with existing packet routing programs. True to the UNIX spirit of modularity, VTun is directly responsible only for tunneling packets between two systems, leveraging established network management tools to provide a cohesive VPN solution.
For the sake of analogy, imagine your home and office networks are a set of discrete and isolated railroad networks. Each machine represents a station. The Linux kernel controls the track switches, determining how trains from one station reach the next. These facilities can be manipulated through the route program, allowing the end user to add or remove destinations.
The Linux kernel also provides facilities for rerouting trains. For example, let's add the Internet, a vast railroad system, to our train station analogy. The home and office networks are merely tiny spurs in this system. Typically, only one station, a firewall or gateway router, has direct access to the larger Internet railroad. If another station on the home tracks wants to dispatch trains to the Internet, these trains first are rerouted through the gateway station. This rerouting process, technically known as IP masquerading or network address translation (NAT), is managed through the iptables program. iptables is the user-space half of the Netfilter firewall code in the 2.4 Linux kernel.
So where does VTun fit into this analogy? Recall that the home and office networks are isolated train systems. A train from home generally is not allowed to cross over to the work tracks due to restrictions at the office firewall station. VTun gives us a facility to lay a virtual track between two stations—for example, your home and office desktops—on the separate networks. Once this track has been laid, the stations are configured using iptables and routed such that trains originating from home can access the work system as freely as if they originated from the office desktop.
Now that we've looked at the components of a VTun VPN, we are ready to examine a complete implementation. The most obvious scenario connects a single remote workstation (your home desktop) to the office LAN by way of your work desktop. To keep this example simple, assume you can establish an SSH connection to your office desktop from home but that the machine is otherwise inaccessible from the Internet. Assume the home network is configured on the 192.168.1.0/24 subnet, and the office network has subnets 192.168.5.0/24 and 192.168.100.0/24.
VTun is a client/server system. The server machine listens for connections from VTun clients on a specified port. The client initiates the creation of the tunnel by connecting to the server port. For this example, the home desktop is the client, and the office desktop is the server.
Before we begin installation, we should take a moment to discuss security. Creation of a VPN can mean the office network now is only as secure as the home network. As such, it is imperative that your home machines are protected by a firewall that is up to date on all security patches and routinely audited for intrusion. Most importantly, never create a VPN without the consent of your office system administrators.
With the caveats and disclaimers out of the way, we proceed to the fun stuff. VTun needs to be installed on both the client and server, so the procedure outlined below should be completed on each system. This procedure has been tested on recent versions of Red Hat Linux. If you discover this installation path fails for your distribution, please send me an e-mail at firstname.lastname@example.org. I will use these responses to track a distribution-specific errata file at www.ryanbreen.com/vtun.
Some distributions already have packages for VTun, so you might be able to save a step by using your package manager to install VTun from your distribution's update site.
As with most VPN solutions, VTun requires the support of kernel-level facilities, in this case provided by the TUN point-to-point network driver. The TUN module is included in the stock kernel distribution, so you most likely do not need to recompile your kernel. As a test, attempt to load the driver by running insmod tun as root. If the module is not found, download the latest version (currently tun-1.1) from vtun.sourceforge.net/tun/index.html. Install it with:
tar xzf tun-1.1.tar.gz cd tun-1.1 su -c 'make install'
If you would like the TUN module to be loaded automatically whenever a process attempts to access the virtual tunnel device, add the following line to /etc/modules.conf:
alias char-major-10-200 tun
Next, configure and install the user-space vtund program. You can find the latest VTun package at vtun.sourceforge.net/download.html. For the sake of generality, here we install from source, but if your distribution supports RPMs or debs, feel free to grab one of the precompiled packages. The latest source tarball at press time is vtun-2.5.tar.gz. Compilation follows the standard procedure:
tar xzf vtun-2.5.tar.gz cd vtun-2.5 ./configure make su -c 'make install'
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
- Three More Lessons
- Django Models and Migrations
- August 2015 Issue of Linux Journal: Programming
- Hacking a Safe with Bash
- The Controversy Behind Canonical's Intellectual Property Policy
- Secure Server Deployments in Hostile Territory, Part II
- Shashlik - a Tasty New Android Simulator
- Huge Package Overhaul for Debian and Ubuntu
- Embed Linux in Monitoring and Control Systems
- KDE Reveals Plasma Mobile