This series of articles covers the development of a Linux-based server
to support a number of workstations running the Microsoft Windows
operating system in the computer laboratory of a 55+ RV Resort in Mesa,
Part I and
Part II covered
the background of our organization, the establishment of our Linux system,
the rules for our iptables firewall and network functions such as IP address serving, a cache-only name
server, an Intranet Web server and print and file services using
the service-message block (SMB) protocol. This article describes the
implementation of a virtual private network (VPN) server, which we built so our
wireless users can encrypt their transmissions over an unsecured network.
The owners of Mesa Regal have supplied the computer lab with superb
equipment, and the resort is being wired with Wi-Fi hotspots that should
make it possible for all residents to have free broadband access from
their RV sites. Some locations will require high-sensitivity antennas, but
the capability will be there. For comparison, most RV resorts that have
Wi-Fi capability charge $20 - $30 per month for it. In the campground where
we are residing as I write this, access is $25 per week! The main
problem is the owners require the network to be unsecured, despite all
recommendations to the contrary. Although most, if not all, sensitive
communications use SSL, many of our members are reluctant to divulge
any information over an unsecured channel. To provide security for them,
I have implemented a VPN server that provides encrypted tunnels from
the user to our Linux machine.
Mick Bauer (see Resources) recently published a complete description
of VPN technologies for Linux. Unfortunately for me, that article was
published after I had finished my setup, but it is an excellent
starting point. In that article, he describes the two different needs
addressed by VPNs. His first case, which allows users to connect to
a private network using an encrypted connection through an untrusted
medium, describes our situation. Once the data has reached our server
and is on the wired network, it is treated exactly the same as material
originating from one of the workstations in the computer lab.
For connecting Windows workstations to the Linux server, we could use
the IP Security (IPSec) protocol, which is highly secure. This method,
however, requires digital certificates and could not be implemented
easily on the many user machines that can be expected to connect through
the VPN server once the Wi-Fi network has been implemented fully. Our
other option is the Point-to-Point Tunneling Protocol (PPTP) designed by
Microsoft and built into all the recent Windows OS releases. In addition,
clients are available for Mac OS X and Linux. Although this protocol
has serious security problems, as described by Schneir and Mudge (see
Resources), v2 of this method is secure enough for our purposes and can
prevent interception by the casual hacker. A determined professional
would be able to crack our network; however, I doubt that we have any
information that would be worth the effort.
Implementing PPTP on Linux
To implement the PPTP server on Linux, I chose the PoPToP package,
v1.2.1 currently maintained by James Cameron (see Resources). This
package consists of a daemon that listens for a connection request on
port 1723. When one arrives, it spawns a process to make a Point-to-Point
Protocol (PPP) connection back to the originating computer. This process
also assigns the IP numbers to be used for both the client and server
ends of this connection. Once our Wi-Fi network is implemented, the
overhead of these various processes and the data encryption/decryption
may overwhelm our server. In that case, a separate machine is be
required. At the moment, we still have plenty of compute power available
to use a single host for all of our services.
The PoPToP package is not a standard feature of the SuSE distribution.
Therefore, I had to download the source package from the Web site, unpack
and configure the software, build the package and install it. These
steps are standard for most software for Linux and are described in the
material contained with the package. In short, they require only a few command-line
entries, and only the installation step requires superuser privileges. The
package also requires that the kernel modules associated with PPP
be available. In particular, ppp_mppe.ko, which handles Microsoft
Point-to-Point Encryption (MPPE), is needed. Additional modules handle
the RC4 cipher used by this method. As long as the default
kernel from the SuSE distribution is used, all necessary modules should
A user that generates a custom kernel, however, has to take some
care when doing the configuration step. In particular, all PPP and all
cryptographic options should be selected. I have done it both ways;
the computer lab system uses the SuSE default, but my test system at
home has a custom kernel that was self-generated. It also is possible
to incorporate Microsoft Point to Point Compression (MPPC). The kernel
must be patched to employ this option, though, which probably is more
effort than it is worth.
When configuring the VPN software, three configuration files
need to be established. The first is /etc/pptpd.conf,
which controls the operation of the PPTP daemon. The default values are
correct for many of the parameters. In our case, only four parameters
need to be defined: the path for the PPP daemon, the path for the
PPP options file, the IP number for the PPP server and the IP
number range for the PPP clients. The values that have been defined in
my configuration are as follows:
ppp /usr/local/sbin/pppd # this tag defines the path of the PPP daemon option /etc/ppp/options.pptpd # the path for the pppd options file localip 10.10.100.1 # the IP number for the PPP server remoteip 10.10.100.100-199 # the range of IP numbers for the clients
This set of parameters configures the network 10.10.100.x for the IP
addresses of the VPN tunnels, with 10.10.100.1 as the IP address of the
server. The standard configuration for PoPToP allows for 100 simultaneous
clients, which is covered by the range specified with the remoteip
tag. Please note that any firewall rules must account for this extra network.
In our network layout, the traffic from the VPN client to the server
enters by way of the external interface and is routed back out through
that same interface on the way to the Internet.
Our options for the PPP daemon are minimal. An unencrypted connection
makes no sense; therefore, we require Microsoft Point to Point Encryption
(MPPE). In addition, the client must utilize v2 of the Microsoft Challenge
Authentication Protocol, MSCHAP- V2. The resulting options.pptpd file
contains the following information:
require-mschap-v2 # required authentication method require-mppe # MPPE encryption required
One note of caution: several versions of the PPP daemon are available
and they have different sets of commands. In fact, the software on my computer
did not match the man pages. I had to read the command parser section
of the code to determine the proper commands to use.
The final configuration file, /etc/ppp/chap-secrets, needed to implement
the VPN server contains the user IDs and the secrets (passwords) needed
for CHAP. As each of our members has a user number and password for
printing, it seems reasonable to use those values as the basis for VPN
authentication. The first few lines of that file are as follows:
# /etc/ppp/chap-secrets file for MRCC VPN connections # client server secret IP Address 0 * xxxxx * 1 * yyyyy * 2 * zzzzz *
The four fields of each line of the file contain, in order, the client
identifier, or the user ID; the server name, an * allows all servers;
the secret; and the IP address for this connection. The *
allows the PPTP daemon to select the address. Two things should be noted here.
First, CHAP is designed to connect computer systems, not users; however,
we ignore this point and use user names and passwords. Second, the
server/client roles are reversed for PPP--the PPTP server becomes the
PPP client. It also is important to note that VPN users do not need
login accounts on the Linux server.
To test if the encryption/decryption processing slows network
traffic, I ran one very crude test. When downloading a Linux kernel
source file from www.kernel.org, the speed of both the open and VPN
links was determined by the T-1 line, without any noticeable slowdown
"Linux in a
Windows Workstation Environment, Part II
Technologies", Mick Bauer, Linux
Journal, February 2005, Issue 130, pp. 30-35.
Larry Finger is retired from the Carnegie Institution of Washington,
Washington DC, and currently is the volunteer technical advisor for
the Computer Club of the Mesa Regal RV Resort, Mesa. Arizona. Besides
maintaining the system described in these articles, he also
collaborates in the development of a program to
display models of crystal
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!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- SourceClear Open
- Parsing an RSS News Feed with a Bash Script
- Google's SwiftShader Released
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