rgb_setup.txt

网上下到的一个很详细介绍VPN基础知识的资料

*
* RCSID $Id: rgb_setup.txt,v 1.6 1999/04/06 04:54:24 rgb Exp $
*

This is an example of a network set up to test the FreeS/WAN KLIPS
package.  It details the hardware setup and the steps necessary to
manually configure and set up two types of connections.  It assumes
that all machines are configured and can talk to each other.

1.  Here is a simplified view of RGB's testbed:


    +---------+						   +---------+
    |  ping4  |						   |  ping5  |
    +----*----+						   +----*----+
   eth0 * 192.168.4.104      	        		   eth0 * 192.168.5.104
	*							*
    *************************               *************************
			*			*
                   eth1 * 192.168.4.110    eth1 * 192.168.5.100
                   +----*-----+	           +----*-----+
                   | gonzales |            | magellan ***-> eth2 to Internet
                   +----*-----+            +----*-----+
		   eth0 * 192.168.2.110    eth0 * 192.168.2.100
			*			*	
	******************************************************************


Only magellan and gonzales need to run IPSEC. 

All netmasks in this example are 255.255.255.0, but yours should reflect
your network architecture.

Ping4 has a route to 192.168.5.x via gonzales, and ping5 has a route to
192.168.4.x via magellan. 

gonzales and magellan know how to route only to their connected subnets;
gonzales does not (yet) know how to get to 192.168.5.x and magellan does
not know how to get to 192.168.4.x. 

First, follow the instructions in the top-level INSTALL to compile and
install the software on both gonzales and magellan, and reboot.

Let us set up gonzales.

ipsec0 needs to be associated with a real interface. In our case,
we shall associate it with the interface on the 192.168.2.0 subnet, that
is, eth0, because that's where IPSEC'ed traffic will flow. Then we
need to configure the new pseudo interface:

	gonzales# ipsec tncfg --attach --virtual ipsec0 --physical eth0
	gonzales# ifconfig ipsec0 192.168.2.110 netmask 255.255.255.0 

On magellan, do the same:

	magellan# ipsec tncfg --attach --virtual ipsec0 --physical eth0
	magellan# ifconfig ipsec0 192.168.2.100 netmask 255.255.255.0 

Note:  The ipsec interface IP, broadcast address and netmask should be
identical to the physical interface to which it is attached.

2. Transport Mode.

Let us have gonzales and magellan communicate securely, using the latest and
greatest IPSEC transform: triple-DES with 96-bits of HMAC-MD5 hash.  This
transform requires an 8-byte (16 nybble) Initialisation Vector
(0x1000000000000001), a 24-byte (48 nybble) encryption key
(0x663066306630663066306630663066306630663066301111) and a 16-byte (32 nybble)
authentication key (0x66306630663066306630663066302222).

To set the actual Security Association, type:

	gonzales# ipsec spi --edst 192.168.2.100 --spi 0x125 --proto esp \
		   --esp 3des-md5-96 \
		   --enckey 0x663066306630663066306630663066306630663066301111 \
		   --authkey 0x66306630663066306630663066302222

To verify it worked, type:

	gonzales# cat /proc/net/ipsec_spi

to get:

	esp0x125@192.168.2.100 ESP_proto_3DES_encrypt_MD5_auth_:  dir=out
		win=0  seq=0  bit=0x00000000  flags=0x0

And set the same SA on magellan, so it will know how to decrypt packets:

	magellan# ipsec spi --edst 192.168.2.100 --spi 0x125 --proto esp \
		   --esp 3des-md5-96 \
		   --enckey 0x663066306630663066306630663066306630663066301111 \
		   --authkey 0x66306630663066306630663066302222

Then, issue the following command, which tells gonzales to process packets
originating with it and destined for magellan by applying a transform
defined by destination address 192.168.2.100 (magellan), SPI 0x125 and
protocol 'esp'.

	gonzales# ipsec eroute --add --src 192.168.2.110/32 \
			--dst 192.168.2.100/32 \
 			--edst 192.168.2.100 --spi 0x125 --proto esp

To verify it has worked, type:

	gonzales# cat /proc/net/ipsec-eroute

you should get:

	192.168.2.110/32 -> 192.168.2.110/32 => esp0x125@192.168.2.110

Last, let's route all the packets destined for magellan through the ipsec0
interface:

	gonzales# route del 192.168.2.100 #(to clear any old routes)
	gonzales# route add -net 192.168.2.100 \
			netmask 255.255.255.255 \
			dev ipsec0 \
			gw 192.168.2.100


If you ping magellan from gonzales, and look at the traffic on the wire,
you'll see that packets from gonzales to magellan are encrypted (and
authenticated), while packets from magellan to gonzales are in the clear.
Needless to say, you can set up a symmetric set of transforms on magellan
and gonzales, repspectively, so that the reverse traffic is also encrypted.

To undo all these commands, work in reverse:

        gonzales# route del 192.168.2.100
	gonzales# ipsec eroute --del --src 192.168.2.110/32 \
			--dst 192.168.2.100/32
	gonzales# ipsec spi 192.168.2.100 125 del
	gonzales# ipsec spi --edst 192.168.2.100 --spi 0x125 --proto esp --del

	magellan# ipsec spi --edst 192.168.2.100 --spi 0x125 --proto esp --del

and don't forget to replace any routes that may have been removed by
the original 'route del' command.

3. Tunnel mode.

3.1.  Set up the tunnel.

Now, we want to set up gonzales so that packets from ping4 to ping5 will be
tunneled through the (gonzales->magellan) tunnel.

We now want to tell the IPSEC code what the processing for packets
which have been selected to be processed with DA=192.168.2.100,
SPI=0x103 and proto=tun. First, they will be encapsulated in simple
IP-in-IP (proto 4) encapsulation, and to enable that we type:

	gonzales# ipsec spi --edst 192.168.2.100 --spi 0x103 --proto tun \
			--ip4 --src 192.168.2.110 --dst 192.168.2.100

This tells the IPSEC code that packets which have been selected to be
processed with DA=192.168.2.100, SPI=0x103 and proto=tun should be run
through IP-in-IP, with "outer" (encapsulating packet) source and
destination addresses of 192.168.2.110 (gonzales) and 192.168.2.100
(magellan) respectively. Type:

	gonzales# cat /proc/net/ipsec-spi

to verify that the SAID has been formed. You should get

	tun0x103@192.168.2.100 IPIP_proto_:  dir=out  flags=0x0
		192.168.2.110 -> 192.168.2.100

Now, issue the following command:

	gonzales# ipsec eroute --add --src 192.168.4.0/24 \
		   --dst 192.168.5.0/24 \
		   --edst 192.168.2.100 --spi 0x103 --proto tun

To verify it has worked, type:

	gonzales# cat /proc/net/ipsec-eroute

you should get:

	192.168.4.0/24 -> 192.168.5.0/24 => tun0x103@192.168.4.0


This means that packets originating from net 192.168.4.x and destined
for net 192.168.5.x should be IPSEC-processed, with a "Destination
Address" of 192.168.2.100, a "Security Parameters Index" of 0x103 and
a "Protocol" of 'tun'.  The Destination Address indicates the other
point of the tunnel, whether it is a real tunnel (as in this case), or
simply the destination (in what we call "transport mode"). The
Security Parameters Index, or SPI, is an opaque value that indicates,
along with the DA and the protocol, what processing these packets will
receive at our end as well as the remote end. The triple (DA, SPI,
Proto) is called a SAID (Security Association IDentifier) in this
document.

The last step is to set up a route to net 192.168.4.0 through the ipsec0
interface:

	gonzales# route del 192.168.5.0 (to clear any old routes)
	gonzales# route add -net 192.168.5.0 \
			netmask 255.255.255.0 \
			dev ipsec0 \
			gw 192.168.2.100

[ To understand what this does, remember that we "attached" eth0 to
ipsec0; the route is set up so that packets will be routed through
magellan, but they will first pass through the ipsec0 interface; then, when
they have been processed, they will be passed on to the attached
interface and delivered to the next-hop specified in the gw parameter
in the route command. ]

3.2  Add security.

So far so good, but we've simply reproduced already existing
functionality. Now, let's add security. First, we'll tell the code to
encrypt packets using the ESP-3DES-CBC transform. We'll create another