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'
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Stunnel Security for Oracle
- SourceClear Open
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Google's SwiftShader Released
- Non-Linux FOSS: Caffeine!
- Parsing an RSS News Feed with a Bash Script
- Doing for User Space What We Did for Kernel Space
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide