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 email@example.com. 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'
Fast/Flexible Linux OS Recovery
On Demand Now
In this live one-hour webinar, learn how to enhance your existing backup strategies for complete disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible full-system recovery solution for UNIX and Linux systems.
Join Linux Journal's Shawn Powers and David Huffman, President/CEO, Storix, Inc.
Free to Linux Journal readers.Register Now!
- The Italian Army Switches to LibreOffice
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Linux Mint 18
- Oracle vs. Google: Round 2
- The FBI and the Mozilla Foundation Lock Horns over Known Security Hole
- Devuan Beta Release
- Varnish Software's Varnish Massive Storage Engine
- Privacy and the New Math
- Ben Rady's Serverless Single Page Apps (The Pragmatic Programmers)
Until recently, IBM’s Power Platform was looked upon as being the system that hosted IBM’s flavor of UNIX and proprietary operating system called IBM i. These servers often are found in medium-size businesses running ERP, CRM and financials for on-premise customers. By enabling the Power platform to run the Linux OS, IBM now has positioned Power to be the platform of choice for those already running Linux that are facing scalability issues, especially customers looking at analytics, big data or cloud computing.
￼Running Linux on IBM’s Power hardware offers some obvious benefits, including improved processing speed and memory bandwidth, inherent security, and simpler deployment and management. But if you look beyond the impressive architecture, you’ll also find an open ecosystem that has given rise to a strong, innovative community, as well as an inventory of system and network management applications that really help leverage the benefits offered by running Linux on Power.Get the Guide