Linux.Desktop.Hacks [Electronic resources] نسخه متنی

Hack 68. Connect to a Microsoft PPTP VPN

At home you are running the "One
True" operating system, but at work you are
languishing in a solid Microsoft shop. Your business is so far into
the Microsoft camp that, horror of horrors, it has chosen to protect
network access using a Microsoft VPN server. It
won't even allow an SSH connection, which means you
can't use port forwarding in SSH to access internal
resources [Hack #75] . As a Linux
user, you can use the plentiful open source tools to access your work
email and files, and even remotely control your desktop PC. All that
is stopping you from this computing-at-home nirvana is being able to
connect to the existing Microsoft VPN server.

To connect and make your work machine available at home, you need to
install some software known as PPTP Client. This package allows a
Linux system to connect to a Microsoft PPTP VPN. The project is
hosted at http://pptpclient.sourceforge.net/, but you
might find the software is already available in your current
distribution. The project web site has details on how to install the
software if your distribution does not include it.

8.15.1. Configuration

Before you can start
using
PPTP Client, you need some information from you network
administrator, namely:

The IP address or hostname of the PPTP server (server)

The authentication domain name (domain)

The username you are to use (username)

The password you are to use (password)

Whether encryption is required

Using this information, you can start editing the configuration
files. Fire up your favorite text editor, create a file called
/etc/ppp/peers/office, and insert the
username and the options file that
contains your PPP configuration to use
(options.pptp). As an example, you could have a
file with the following settings:

# PPTP Tunnel configuration for tunnel office
#
# Specify our login username (may need to be domain\\username)
#
name username
#
# get all other options from the file /etc/ppp/options.pptp
#
file /etc/ppp/options.pptp

Depending on the VPN server you are connecting to, you might have to
change username to
domain\\username, where both values are
replaced with the information your network administrator gives you.
Next, edit the /etc/ppp/options.pptp file, which
should contain the following:

#
# Lock the port
#
lock
#
# We don't need the tunnel server to authenticate itself
#
noauth
#
# Turn off transmission protocols we know won't be used
#
nobsdcomp
nodeflate
#
# We want MPPE
#
require-mppe

If your kernel does not already support it, you also need MPPE
support to be built-in. Run this command as root:

foo@bar:~# modprobe ppp-compress-18

If the module loads without error, everything is well; otherwise, you
need to obtain or build the ppp_mppe kernel
module. If you are using a stock distribution kernel, this could be
as simple as installing the required package. If a package
isn't available, you need to build a custom kernel.
The required kernel option (using menuconfig) is Network Device
SupportPPP (point-to-point protocol) SupportPPP
MPPE Compression (encryption).

You also need to use Version 2.4.2 or above of the
ppp package. Now you need to edit the
/etc/ppp/chap-secrets file to contain the
following:

## OUTBOUND CONNECTIONS
username
"*"  
password

Again, you should replace both username
and password with the values your network
administrator gives you. If you are running a firewall at your end
(you should be!), you need to configure the firewall to allow all
packets out on TCP port 1723 to the VPN server. This is used to
negotiate the connection and to pass link control traffic. The only
other change that is required is to allow all GRE protocol packets
(protocol number 47) between the client system and the VPN server.
You should do this for both inbound and outbound traffic.

8.15.2. Starting the VPN

Now everything should be ready to go. To make a connection, log in as
root and run the following command:

foo@bar:~# pptp-command start office
Using interface ppp0
Connect: ppp0 <--> /dev/pts/1
MPPE 128-bit stateless compression enabled
Cannot determine ethernet address for proxy ARP
local  IP address www.vvv.xxx.yyy
remote IP address www.vvv.xxx.zzz
pptp-command: added route add default dev ppp0
Tunnel office is active on ppp0. Local IP Address: www.vvv.xxx.yyy

Now try pinging a server on the remote end, which should give a
result similar to the following:

foo@bar:~# ping -c 1 www.vvv.xxx.aaa
PING www.vvv.xxx.aaa (www.vvv.xxx.aaa) 56(84) bytes of data.
64 bytes from www.vvv.xxx.aaa: icmp_seq=1 ttl=126 time=45.8 ms
--- www.vvv.xxx.aaa ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3002ms
rtt min/avg/max/mdev = 42.745/45.541/48.479/2.052 ms

8.15.3. Applications

OK, so now you should have a working connection to the office VPN
server (and the office LAN), so what are you going to do with it?
Perhaps the simplest thing to do now is to launch your favorite web
browser, and point it at the company's intranet
server. If you have a Microsoft Exchange server, try pointing your
web browser at http://mailserver/exchange, where
mailserver is the actual name of your Exchange
server. Then you should be able to log in with your username and
password and access your email. Alternatively, you can set up the
email client on your Linux machine to pull mail from your corporate
mail server, or you can access your work machine via RDP if it is a
Windows XP desktop, or VNC if it is anything else [Hack #30] . Basically, once you have a
VPN connection to your corporate network, you can do anything you
would do at work, just a little more slowly.

It is important to remember that all packets passing over the VPN are
encrypted, which introduces a bit of latency. This does not normally
present a problem with most applicationse.g., web, email, file
transfers. Some applications, such as Voice over IP, will be affected
by this latency and will require careful tuning to operate
successfully.

Ron Wellsted