لطفا منتظر باشید ...
Configuring a
Linux FreeS/WAN Server
FreeS/WAN is a more Linux-centric VPNsolution than is PPTP, but considered broadly, both serve a similar function:
linking two or more computers or networks in a secure way over an insecure
network, such as the Internet. As with PPTP, the first step in running a
FreeS/WAN VPN is obtaining and installing the software. You can then begin
configuring the system and establishing a link between FreeS/WAN systems.
FreeS/WAN is actually a very sophisticated
package, with more options than can be covered in this chapter. For more
information, consult the FreeS/WAN documentation, and particularly the
configuration manual,
target="_blank">http://www.freeswan.org/freeswan_trees/freeswan-1.91/doc/configl .
Obtaining and Installing FreeS/WAN
In early 2002, few Linux distributions shipwith FreeS/WAN, but there are exceptions. Most notably, SuSE comes with the
package, and a Mandrake package is also readily available. You should check
your distribution to be sure it doesn''''t come with FreeS/WAN before obtaining it
from the main FreeS/WAN Web site, target="_blank">http://www.freeswan.org . This site (or more precisely, the FTP site to which it links,
explicit kernel support that''''s not standard in the Linux kernel, so to use it,
you must recompile your kernel, as described shortly. If you install a
FreeS/WAN package that came with your distribution, chances are these kernel
changes are part of the kernel that came with the distribution, so your
configuration task is simpler. The rest of this section assumes you''''re
installing FreeS/WAN using its source code.
If you compile FreeS/WAN from source code,
you must have several components installed on your system:Standard development
tools You must have typical development tools,
such as GCC, make , and normal libraries and library headers. Such tools are installed
on most Linux systems by default.
Kernel source code The FreeS/WAN compilation tools automatically change your Linux
kernel source tree, in /usr/src/linux . This tree should therefore contain your current
kernel source code. If you''''re using your distribution''''s standard kernel, you
should be able to install a matching source code package. You''''ll later have to
recompile the kernel and reboot. If you plan to change your kernel''''s
configuration, you should do this (with make menuconfig , make xconfig , or a similar command) prior to compiling FreeS/WAN. You may want
to make the kernel and test it before proceeding further.
GMP library FreeS/WAN relies upon the GNU
Multi-Precision (GMP) library ( target="_blank">http://www.swox.com/gmp/ ). This package is available on most distributions, so try to find
it and install it from your installation CD-ROM or your distribution''''s main FTP
or Web site.
Ncurses library Some configuration options use the ncurses library. This isn''''t
strictly required, but it''''s very helpful. It''''s also very common, so it may
already be installed.
To make and install the FreeS/WAN package,
follow these steps:
Make sure you''''ve got all the
components described earlier, such as your kernel source code and the GMP
library.
2.
Uncompress the FreeS/WAN package
in some convenient location, such as /usr/src . ( Do not copy or move the freeswan-version directory after uncompressing it; the directory contains symbolic links that
are sensitive to changes.)
3.
Change into the FreeS/WAN source
code directory and type a command to configure the package, patch the Linux
kernel, and make the FreeS/WAN package. You can use make oldgo to use your existing Linux kernel configuration and default FreeS/WAN settings,
make ogo to use the kernel''''s make config configure utility, make menugo to use the kernel''''s make menuconfig , or make xgo to use the kernel''''s make
xconfig . The last three of these options run you
through the specified kernel configuration routine so that you can change
kernel options. In any event, the last line of output should report that the
system was calling an errcheck script. If you don''''t see this line, it means that something went
wrong. You can check the out.kpatch and out.kbuild files for information on the patching and building process for
clues to what went wrong.
4.
Type make kinstall to rebuild your kernel. This process builds the kernel and its
modules, and uses the kernel''''s make modules_install process to install
the new kernel modules. If there are any errors, they should appear in the out.kinstall file.
5.
Reconfigure LILO, GRUB, or
whatever method you''''re using to boot your Linux kernel to handle the new
kernel. You may need to copy your new kernel file from /usr/src/linux/arch/architecture-code/
boot , edit /etc/lilo.conf or some
other configuration file, and type lilo or some other
boot loader command.
6.
Reboot the computer. Be sure to specify the correct new
FreeS/WAN-enabled kernel if you have a choice.
At this point, your system should be working with a kernel
that''''s capable of supporting FreeS/WAN. As part of the process, FreeS/WAN
should have created a file called /etc/ipsec.secrets ,
which contains encryption keys. You''''ll need to deal with this file later, so
for now you should check that it exists and contains some keys (which resemble
hexadecimal gibberish).
In order to be useful, you must configure FreeS/WAN on at
least two computers, presumably on different networks. The installation process
is the same on both. In many cases, both systems will be configured as routers,
although you can install FreeS/WAN on a single system that''''s to connect to a
remote network.
Editing
Configuration Files
FreeS/WAN uses two configuration files: /etc/ipsec.secrets and /etc/ipsec.conf . Each is important andplays a different role. The first contains encryption keys, which the servers
use to identify themselves to each other. The second controls general-purpose
configuration options.
Setting
Up Keys
As noted earlier, the FreeS/WAN build process should havecreated an /etc/ipsec.secrets file
that contains encryption keys. If this file isn''''t present, or if it doesn''''t
contain a key you want to use, you can generate a new key with the following
command:# ipsec rsasigkey 128 > /root/rsa.key
This command creates a 128-bit key and places it in the /root/rsa.key file. You can generate a key
of some other length by specifying the desired length instead of 128 in the preceding example. The output
of this command isn''''t quite what''''s needed, though. Specifically, you must add
the following line to the start of the file:: RSA {
Be sure to include the spaces around RSA . You must also add a line containing
at least one space followed by a single right curly brace ( } ) to the end of the file. You can then
copy the result into the existing /etc/ipsec.secrets
file, replacing the current : RSA {
block in that file. You should perform this step on both the FreeS/WAN VPN
routers.
NOTE
The output of the ipsec
rsasigkey command includes a comment to the effect that the key
is only useful for authentication, not for encryption. This is fine;
FreeS/WAN uses the key in precisely this way, and uses other algorithms for
encryption.
The output of the ipsec
rsasigkey command includes a commented-out line that begins #pubkey= . This sets the public key that
you must give to other systems with which this system must communicate. You
should make note of it now, because you''''ll need to enter it into the /etc/ ipsec.conf file of your other
systems.
Editing
the IPSec Settings
Most FreeS/WAN installations create a default /etc/ipsec.conf file. This file isn''''tterribly useful as is, but it can be used as a good template for configuring
your system. The file has three basic types of setup sections: config setup , conn %default and conn
remotename .
Adjusting
Local Options
The config setup section specifies local settings. The default example section resembles the
following:config setup # THIS SETTING MUST BE CORRECT or almost nothing will work;# %defaultroute is okay for most simple cases.
interfaces=%defaultroute # Debug-logging controls: "none" for (almost) none, "all" for \ lots.
klipsdebug=none plutodebug=none # Use auto= parameters in conn descriptions to control startup \ actions.
plutoload=%search plutostart=%search # Close down old connection when new one using same ID shows up.
uniqueids=yes
The most important setting in this section is the interfaces line, which tells FreeS/WAN
which interfaces to use for VPN connections (that is, where it can find VPN
partners). The default value of %defaultroute
tells FreeS/WAN to use your default route, which normally connects to all non
local IP addresses. You might want to specify particular interfaces, though.
For instance, the following option tells the system to use eth0 and ppp1 :interfaces="ipsec0=eth0 ipsec1=ppp1"The klipsdebug
and plutodebug options set the
logging options for the Kernel IP Security (KLIPS)
kernel features and for the Pluto daemon, which is a part of the FreeS/WAN
package that handles key exchange. You can set these to all if you''''re having problems.
Pluto can load connections into memory or start them
automatically when FreeS/WAN starts up. The plutoload
and plutostart options tell the
system with which connections it should do this. The default value works well
in most cases, but if you want to specify just some connections, you can name
them instead. The drawback to listing individual FreeS/WAN servers is that if
one crashes, it may not come back up into the VPN automatically after
restarting.
Adjusting
Default Remote Options
Individual connections are defined through sections that beginwith the keyword conn . FreeS/WAN
supports a %default connection
name for setting default connection options. Options you''''re likely to see in
this section include the following: keyingtries
In the event of a connection failure, FreeS/WAN normally retries the
connection. A default value of 0
for this option makes FreeS/WAN infinitely persistent, but if you want to limit
the number of times it retries its connections, set this value lower. You might
want to do this when you''''re first testing your setup.
authby The
usual authentication method uses authby=rsasig ,
which causes the system to use RSA keys. Another method uses shared secrets, but this chapter only covers RSA key
authentication.
In addition to these options, it''''s possible for various other
options described in the next section, "
to appear in a default connection section. If you find yourself entering the
same options for several connections, you might move them all to the default
configuration to reduce the chance of a typo causing problems and to shorten
the configuration file.
Adjusting
System-Specific Remote Options
Each connection requires some customization, which is done ina conn section. The connection
name follows conn , and that
connection''''s options follow on subsequent lines, all of which are indented at
least one space. Many of the options in this section relate to network interfaces.
To help understand this, consider
network. The configuration is described from the top ("left") VPN
router. You must tell FreeS/WAN about various IP addresses used in this
configuration. You do so with several options:
Figure 26.6. A FreeS/WAN
configuration requires you to identify several computer and network addresses
involved in creating the VPN.
This is the local subnet to which the FreeS/WAN router is
connected172.16.0.0/16 in the case of
is the address associated with the VPN server''''s external interface. This can be
set to %defaultroute in most
cases, or you may want to provide an exact IP address, such as 10.0.0.1 in
This is the IP address of the conventional router to which the VPN system
connects, such as 10.0.0.10 in
because KLIPS bypasses the normal kernel routing machinery and sends the data
directly to the next router.
leftfirewall
If the subnet that the VPN router serves uses nonroutable IP addresses with
NAT, or if the VPN router also functions as a firewall, set leftfirewall=yes . This adjusts the way
FreeS/WAN treats packets to support firewall functionality.
rightnexthop
This is the mirror of the leftnexthop
entry; it''''s the IP address of the conventional router that delivers packets to
the remote network. Note that this is the IP address of this router as seen by
the remote FreeS/WAN system.
right This
entry corresponds to the remote VPN router''''s external network interface. Unlike
left , you can''''t leave this entry
set at a default.
rightsubnet
This is the IP address block of the remote network, such as 192.168.1.0/24 in
This is an identifier for the left system. This can be an IP address, a domain
name, a hostname preceded by an at-sign (such as @vpn.threeroomco.com ) or a username and hostname (much like
an e-mail address, such as emily@vpn.threeroomco.com ).
The hostname preceded by the at-sign indicates that the system shouldn''''t try to
resolve the name into an IP address. As a general rule, this is the best form
to use because it''''s reasonably memorable and won''''t cause problems if DNS is
down.
rightid
This is just like leftid , but it
identifies the other side of the VPN link.
leftrsasigkey
This is the RSA public key value from the /etc/
ipsec.secrets file on the left VPN server. You should cut and paste
this value if you''''re configuring the left system, or transfer the file and then
copy and paste it if you''''re configuring the right system.
rightrsasigkey
This is the RSA public key value from the /etc/
ipsec.secrets file on the right VPN server.
auto This
option, in conjunction with the plutoload
and plutostart options in the conn setup section, controls which
networks are loaded or started when FreeS/WAN starts up. Specifically, if plutoload= %search and auto=add , then the configuration is
loaded; if plutstart=%search and
auto=start , then the
configuration is started. For initial setup and testing, auto=add is a good configuration because
this allows you to manually start connections. Once you set up a production
system, auto=start usually works
better because it requires no manual intervention to start the connections.
The labeling of a system or network as left or right is
arbitrary. One useful mnemonic may be to give the link a name that includes
both ends, such as boscinci for a VPN linking Boston and Cincinnati offices. You can then call
the Boston side left and the Cincinnati end right , reflecting their
positions in the name. You use the same configuration on both sides of the
link; FreeS/WAN figures out which end it is by examining the system''''s existing
network connections.
Establishing a Link
The basic procedure for establishing a linkbetween two FreeS/WAN routers is to start the ipsec program as a daemon
on one and to use the same program to initiate a connection from the other
computer. Once you''''ve tested the connection, it should be started automatically
whenever you start the computers and run ipsec on both. It doesn''''t
matter which system you use in daemon mode and which you use to manually start
the connection when you do this stage of the testing; unlike PPTP, FreeS/WAN
makes little distinction between clients and servers.
To start FreeS/WAN in daemon mode, type the
following command:# ipsec setup start
This starts the server and, depending upon
the configuration of the plutoload , plutostart , and auto options described earlier, the system loads a configuration and
waits for a connection or tries to initiate a connection. If you configured
your systems as described earlier, with auto=add on both ends of
the connection, you can start the server on one end and it will wait for a
connection request from the other system. This will occur when you type the
following command on the system that''''s not yet running the program:# ipsec auto --up name
In this example, name should be the name of a connection link, such as boscinci . The system
should attempt to start up that link. You can check to see if it was successful
by typing ipsec look . If you receive a set of encryption information and a VPN routing
table as output, then the connection was successful. You can also try using
normal networking commands, like ping , traceroute , and telnet , to see
if you can establish connections with systems on the remote network, and to
verify that they''''re being routed via the VPN. Remember that, if the remote
network is publicly accessible from the Internet at large, tools like ping won''''t
verify that the connection is via the VPN. You should use protocols that are
blocked from scrutiny by the general public, or from your local public
addresses, to test your VPN functionality.
Once you''''ve gotten your network up and
running, you can change the configuration of auto in /etc/ipsec.conf . If you set this to start on both ends, the startup will be
automatic whenever the ipsec
setup start command is issued. You can start
FreeS/WAN in this way by starting it in a SysV or local startup script, as
described in
