Quick HOWTO : Ch35 : Configuring Linux VPNs/zh

文章出处:

{{#if: | {{{2}}} | http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:_Ch35_:_Configuring_Linux_VPNs }}

翻译人员:

sanebaby

{{#ifexist: :Quick HOWTO : Ch35 : Configuring Linux VPNs/zh/zh | | {{#ifexist: Quick HOWTO : Ch35 : Configuring Linux VPNs/zh/zh | | {{#ifeq: {{#titleparts:Quick HOWTO : Ch35 : Configuring Linux VPNs/zh|1|-1|}} | zh | | }} }} }} {{#ifeq: {{#titleparts:Quick HOWTO : Ch35 : Configuring Linux VPNs/zh|1|-1|}} | zh | | }}

介绍

随着 SOHO 的增长，你最终需要建立一些安全的连接到供应商、卖主、分支机构、商业伙伴或是顾主，以便能够联入他们的位于Internet 防火墙后面的服务器。

一种解决办法就是建立虚拟专用网络(VPN)在你的防火墙和他们之间提供加密的数据流。VPN十分方便，因为你能不依靠公网IP地址，而仅靠私有IP地址连接到远程服务器。这样就避免了连接服务器的网络地址转换的问题。

本章将概述如何使用 Openswan (Linux下流行的VPN软件) 构造一个固定的点对点的VPN连接。

如果你对VPNs不熟悉，请看附录I，"Miscellaneous Linux Topics"， 提供了一些对深入理解本章要点重要的背景知识。

VPN 指引

这有一些推荐的指引，建议你在尝试建立SOHO Linux VPN前看一下。

• VPNs的IP安全协议基于数据包不能实现网络地址转换。如果你的防火墙用作NAT，那么你将不能在VPN中传输数据包。

• 如果你将你的linux 加入 VPN 同时也用作防火墙，生活将会更简单。配置VPN前要配置和测试防火墙。第14章"Linux Firewalls Using iptables"，应该能给你不少帮助。

• VPN tunnel 必须在网络中使用不同的IP地址。许多公司网络使用的是192.168.0.x 或 192.168.1.x 地址段，如果IP地址重复，你可以为你的网络重新指定IP地址。

• 固定的点对点VPNs要求防火墙使用静态、DHCP IP地址。

纲要

插图35-1说明了2个SOHO环境里的VPN网络之间的拓扑结构。下面是说明。

• 两地之间通过VPN连接，能够不用担心被窃听。

• 两地的网络管理员需要知道永久的点对点VPN需要固定的Inernet IP，需要到他们的原始DHCP服务的ISPs 那里升级。

• 通信双方都不会想要投资一个证书认证机构或者一套基础设施. 密钥交换将采用RSA技术. (在本章结束, 我会讨论另一种Cisco支持的叫做共享密钥，预先共享，或者对称密钥的交换技术。

• 站点 1 属于私有网络 172.168.1.0 /24 ，这个网络有一个 Linux VPN/防火墙 设备作为默认网关，网关外部地址是 97.158.253.25.

• 站点 2 属于私有网络 10.0.0.0 /24 ，这个网络有一个 Linux VPN/防火墙 设备作为默认网关，网关外部地址是 6.25.232.1.

Figure 35-1 Openswan 拓扑结构示意图

下载并安装 Openswan 软件包

你可以从 www.openswan.org 下载Openswan的RPM包. 这个网站上有关于如何在Fedora和其他版本Lnux上安装该产品的很好的说明。注意，要使用RPM版本的Openswan，你的系统必须已经装好了 ipsec-tools 包。 (RPM包一般以软件名和版本号开头，例如 Openswan-2.1.4-1.fc2.i386.rpm. 如果你需要知道更多细节，参考第六章 "Installing Linux Software".

如何启动 Openswan

你可以用 chkconfig 命令配置Openswan在系统启动时运行：

[root@bigboy tmp]# chkconfig ipsec on

启动后你可以用ipsec初始化脚本启动，停止，重新起动Openswan：

[root@bigboy tmp]# service ipsec start
[root@bigboy tmp]# service ipsec stop
[root@bigboy tmp]# service ipsec restart

每次修改过 ipsec.conf 文件后，要使修改生效，必须重启ipsec进程。

查看Openswan安装状态

安装Openswan之后，运行 ipsec verify 命令。多数检查结果应该是 [OK]

[root@vpn2 tmp]# ipsec verify
Checking your system to see if IPsec got installed and started correctly
Version check and ipsec on-path                               [OK]
Linux Openswan U2.2.0/K2.6.8-1.521 (native)
Checking for IPsec support in kernel                          [OK]
Checking for RSA private key (/etc/ipsec.secrets)             [OK]
Checking that pluto is running                                [OK]
Two or more interfaces found, checking IP forwarding          [OK]
Checking NAT and MASQUERADEing                                [N/A]
Checking for 'ip' command                                     [OK]
Checking for 'iptables' command                               [OK]
Checking for 'setkey' command for native IPsec stack support  [OK]
[root@vpn2 tmp]#

如何处理常见的状态错误

状态检查会提供一些错误信息。最常见的是与IP转发和随机加密（Opportunistic Encryption）相关的错误

IP 转发

每个Linux VPN设备都要启用路由和IP转发。要启动这些功能，只要往 /etc/sysctl.conf 文件中加入 ip_foward项即可。

#
# File: /etc/sysctl.conf
#
#---------------------------------------------------------------
# Enable routing (IP forwarding)
#---------------------------------------------------------------
 
net/ipv4/ip_forward = 1

现在用 sysctl -p 命令激活这些设定：

[root@bigboy tmp]# sysctl -p
...
...
net.ipv4.ip_forward = 1
[root@bigboy tmp]#

你可以在附件I, "Miscellaneous Linux Topics." 中找到更多关于 /etc/sysctrl.conf的细节。

随机加密DNS检验（Opportunistic Encryption DNS Checks）:

Openswan的随机加密DNS检查功能允许网关加密流量，即使两个网关管理者没有事先联系并且两个系统也分别都没有关于对方的任何预设信息。其背后的原理是对所有VPN设备后面服务器的连接都用IPSec自动加密，与HTTP流量可以被无缝加密成HTTPS流量一样。

这个特性在配置文件中默认是禁用的；忽略与其相关的错误。

VPN配置步骤 (使用RSA密钥)

One of the more secure ways of setting up a VPN tunnel is to encrypt the data using certificate-based (RSA) keys. There are other VPN parameters too, but Openswan is very forgiving when it establishes a tunnel. It automatically goes through all the various combinations of IKE and IPSec settings with the remote VPN box until it finds a match. You don't have to configure most of these settings explicitly as you often have to do in the case of routers and firewall/VPN appliances.

/etc/ipsec.conf 配置文件

Preparation work requires you to draw a basic network diagram such as Figure 35.1. The VPN box on the left is called the left-hand side and the one on the right is called the right-hand side. Left and right parameters must be configured in the /etc/ipsec.conf configuration file. Table 35-1 explains each parameter.

Table 35-1 Parameters of the /etc/ipsec.conf file

Parameter	Description
Left	Internet IP address of the left-hand side VPN device.
Leftsubnet	The network protected by the left-hand side VPN device.
Leftid	Fully qualified domain name in DNS of the left-hand side VPN device, which is preceded by an "@" sign. If DNS is set up for the IP addresses, remove this entry, because names that don't resolve correctly cause the VPN initialization to fail.
Leftrsasigkey	The entire left RSA sig public key for the left-hand side VPN device. This can be obtained by using the ipsec showhostkey --left command.
Leftnexthop	The next hop router from the left-hand side VPN device when trying to reach the right-hand side VPN device. You may use an auto-generated variable %defaultroute, which will be valid in most cases, or the actual IP address of the next hop router in cases where the next hop is not the default router.
Right	Internet IP address of the right-hand side VPN device.
Rightsubnet	The network protected by the right-hand side VPN device.
Rightid	Fully qualified domain name in DNS of the right-hand side VPN device, which is preceded by an @ sign. If DNS isn't set up for the IP addresses, remove this entry, because names that don't resolve correctly cause the VPN initialization to fail.
Rightrsasigkey	The entire right RSA sig public key for the right-hand side VPN device. This can be obtained by using the ipsec showhostkey --right command.
Rightnexthop	The next hop router from the right-hand side VPN device when trying to reach the right-hand side VPN device. You may use an auto-generated variable %defaultroute, which will be valid in most cases, or the actual IP address of the next hop router in cases where the next hop is not the default router.

First you must gather all this information, then you have to enter it in the /etc/ipsec.conf configuration file.

获取 RSA 密钥

To configure the /etc/ipsec.conf file, you need to get the left RSA public key for the left VPN device and the right key for the right VPN device. You need to generate these and insert them in the /etc/ipsec.conf file of the VPN peer device.

The best approach is to generate files containing these keys and then use the vi editor's read command (r) to read them into your /etc/ipsec.conf file. Cutting and pasting screen output over an SSH session may automatically insert carriage return and line feed characters at the end of each line where the text would normally wrap around on the screen. This can corrupt the keys.

创建你自己的密钥

The Openswan installation automatically generates the keys. If you want to change them, you can issue the command:

[root@vpn2 tmp]# ipsec rsasigkey --verbose 2048 > keys.tmp
[root@vpn2 tmp]#

You can then edit the /etc/ipsec.secrets file and replace the contents between RSA: { and the final } with the contents of the keys.tmp file generated from the ipsec command above.

获得服务器端公钥

On the left VPN server, issue this command to export the left public key to a file named /tmp/left.pub.

[root@vpn1 tmp]# ipsec showhostkey --left > /tmp/left.pub
[root@vpn1 tmp]#

获得客户端公钥

On the right VPN server, export the right public key to a file named /tmp/right.pub.

[root@vpn2 tmp]# ipsec showhostkey --right > /tmp/right.pub
[root@vpn2 tmp]#

Edit the /etc/ipsec.conf Configuration File

Each VPN in the /etc/ipsec.conf file has its own subsection. The example creates a subsection called net-to-net, which then receives all the needed parameters.

#
# File: /etc/ipsec.conf
#
conn net-to-net
  left=97.158.253.25              # Public Internet IP address of the
                                  # LEFT VPN device
  leftsubnet=172.16.1.0/24        # Subnet protected by the LEFT VPN device
  [email protected]        # FQDN of Public Internet IP address of the
                                  # LEFT VPN device with an "@"
  leftrsasigkey=0sAQNrV9AYdaW94FXvIxu5p54+MRaW0wy0+HHQrdGofklZYQ4TCBlL+Ym00Ahfc8mqXlerZY12Os41G
8SIV+zzIO04WZ4wmOvEr8DZaldTbfCuvUvMhrTtCpZdm53yF5rCaUbg+Vmx71fgyVmGu8/kuhzB7nWtOYqDFO8OHDGePOyO
VPQi73KfRoDbdb3ND0EtfnRhRPblKJ239OlIq1
  leftnexthop=%defaultroute       # correct in many situations
  right=6.25.232.1                # Public Internet IP address of
                                  # the RIGHT VPN device
  rightsubnet=10.0.0.0/24         # Subnet protected by the RIGHT VPN device
  [email protected]  # FQDN of Public Internet IP address of the
                                  # RIGHT VPN device with an "@"
  rightrsasigkey=0sAQNNdxFPWCga+E/AnDgIM+uIDq4UXcZzpomwMFUpyQ9+rhUHT9w8nr3rjUR/qTZOKR2Vqd4XoBd1s
HkPDBQ8oNjtA3Oz+UQOU3KTMHN5ydFwe6MpTJV/hL6LvhB0OXQad/NhjMIx8vOnhM8g8SPRnj7pL3abgu7Sg7eFREV1MJSVB
h p0DJ0EbVMVV+Xvwlm9++9zbY3mlc+cSXMPAJZ
  rightnexthop=97.158.253.25      # correct in many situations
  auto=start                      # authorizes and starts this connection
                                  # on booting

关于 /etc/ipsec.conf 的几点重要说明

Be sure to maintain the indentation before each parameter. The correct arrangement is.

conn net-to-net
   left=x.x.x.x
   leftsubnet=y.y.y.y/24

Do not use

conn net-to-net
left=x.x.x.x
leftsubnet=y.y.y.y/24

The net-to-net subsections must be the same in the /etc/ipsec.conf for both the left- and right-hand side VPN devices. You can configure VPNs to other remote destinations in this file as long as they don't share a subsection name with other VPNs. So in this example, there should be only one net-to-net subsection which uniquely defines the VPN between our two sample sites.

Also, make sure no blank lines separate the net-to-net section's parameters. Lines commented with a # character are acceptable.

Restarting IPSec to reload the configuration file doesn't necessarily restart the tunnels. If you set the auto= parameter to add, you can start the tunnel only manually with the ipsec command. If the parameter is commented out, then the tunnel will never start. A value of start causes the tunnel to start automatically.

重启 Openswan

On both VPN devices, you need to start Openswan for the new /etc/ipsec.conf settings to take effect.

[root@vpn2 tmp]# service ipsec restart
ipsec_setup: Stopping Openswan IPsec...
ipsec_setup: Starting Openswan IPsec U2.2.0/K2.6.8-1.521...
[root@vpn2 tmp]#

初始化新管道

To initialize the new tunnel, you can use the ipsec command to start the tunnel net-to-net. Be sure to issue the command simultaneously on the VPN boxes at both ends of the tunnel.

[root@vpn2 tmp]# ipsec auto --up net-to-net
104 "net-to-net" #1: STATE_MAIN_I1: initiate
106 "net-to-net" #1: STATE_MAIN_I2: sent MI2, expecting MR2
108 "net-to-net" #1: STATE_MAIN_I3: sent MI3, expecting MR3
004 "net-to-net" #1: STATE_MAIN_I4: ISAKMP SA established
112 "net-to-net" #2: STATE_QUICK_I1: initiate
004 "net-to-net" #2: STATE_QUICK_I2: sent QI2, IPsec SA established {ESP=>0xe0bdd0e9 <0x13ac7645}
[root@vpn2 tmp]#

The "IPsec SA established" message signifies success.

测试新管道

The troubleshooting section at the end of the chapter shows you how to test that everything is working correctly.

Possible Changes To IP Tables NAT/Masquerade Rules

If you are running iptables with masquerading/NAT for the VPN devices, then you must exclude packets traversing the tunnel from the NAT operation. This example assumes that interface eth0 is the Internet facing interface on your Linux VPN/firewall.

Change the left-hand side VPN device's iptables statement from.

iptables -t nat -A POSTROUTING -o eth0 -s 172.168.1.0/24 -j MASQUERADE

to

iptables -t nat -A POSTROUTING -o eth0 -s 172.168.1.0/24 -d \! 10.0.0.0/24 -j MASQUERADE

For the right-hand side VPN device, change the statement

iptables -t nat -A POSTROUTING -o eth0 -s 10.0.0.0/24 -j MASQUERADE

to

iptables -t nat -A POSTROUTING -o eth0 -s 10.0.0.0/24 -d \! 176.16.1.0/24 -j MASQUERADE

令 Openswan 自动启动

If your VPN subsection in the /etc/ipsec.conf file contains the line auto=add, then IPSec only authorizes but doesn't establish the connection at startup. You'll have to use the ipsec auto --up <vpn-name> command to start it manually.

You must change this to auto=start for Openswan to start the VPN automatically when IPSec restarts or when the system reboots.

使用 Pre-Shared Keys (PSK)

You don't always have to use RSA type keys. Sometimes the VPN device at the other end of the tunnel won't support them, but will accept a simpler pre-shared key. Here is how to do it.

1) Create the PSK using one of two methods. You can create a random pre-shared key using the ipsec command.

[root@vpn2 tmp]# ipsec ranbits --continuous 128
0x33893a081b34d32a362a46c404ca32d8
[root@vpn2 tmp]#

Or, you can create them out of your head. Make them long (over 20 bytes), as in.

Nonebutourselvescanfreeourminds

2) Update /etc/ipsec.secrets by adding text in this format at the beginning of the file.

vpn1-ip-address vpn2-ip-address : PSK "key in quotations"

For the example the line is:

97.158.253.25 6.25.232.6 : PSK "nonebutourselvescanfreeourminds"

3) Update /etc/ipsec.conf. The PSK configuration is very similar to the RSA configuration with exception that the leftid, rightid, leftrsasigkey, and rightrsasigkey fields are omitted from the relevant conn subsection. Also add the authtype=secret command to the configuration.

conn net-to-net
    authby=secret                # Key exchange method
    left=97.158.253.25           # Public Internet IP address of the
                                 # LEFT VPN device
    leftsubnet=172.16.1.0/24     # Subnet protected by the LEFT VPN device
    leftnexthop=%defaultroute    # correct in many situations
    right=6.25.232.1             # Public Internet IP address of
                                 # the RIGHT VPN device
    rightsubnet=10.0.0.0/24      # Subnet protected by the RIGHT VPN device
    rightnexthop=97.158.253.25   # correct in many situations
    auto=start                   # authorizes and starts this connection
                                 # on booting

Remember to have the same configuration on the Linux VPN boxes on either side of the tunnel and to restart Openswan to activate the new settings.

Openswan 常见问题

Troubleshooting is always important when setting up VPNs, because many things can go wrong. Here are some quick checks you can do to make sure all is working correctly.

检查管道状态

The ipsec auto --status command provides a status on Opesnswan running on your VPN device. The output is divided into three sections:

• IKE Section: Defines the various encrypted key exchange algorithms and their parameters. At least one set of values must match between the left- and right-hand side VPN devices. This is also frequently referred to as the Phase 1 parameters, because the key exchange process is the first thing to occur in establishing a VPN.

• ESP Section: Defines the various data encryption algorithms and their parameters. At least one set of values must match between the left- and right-hand side VPN devices. This is also frequently referred to as the Phase 2 parameters, because the data encryption process is the second and final thing to occur in establishing a VPN.

• VPN Section: This is usually prefaced by the name of the VPN tunnel, in this case net-to-net. If there are no entries, then the VPN hasn't been established at all. If there are entries, but no STATE_QUICK_R2 (IPsec SA established) lines then the IPSec parameters are configured, but the tunnel hasn't been established. This can be normal, tunnels become active once the Phase 1 and Phase 2 security associations are created, and this usually only occurs after traffic is flowing. The associations then get torn down after a timeout period. It is always best to pass traffic over the tunnel to activate them. An ICMP ping check is a good way to test this.

[root@vpn2 tmp]# ipsec auto --status
...
...
000 algorithm ESP encrypt: id=2, name=ESP_DES, ivlen=8, keysizemin=64, keysizemax=64
000 algorithm ESP encrypt: id=3, name=ESP_3DES, ivlen=8, keysizemin=192, keysizemax=192
000 algorithm ESP encrypt: id=7, name=ESP_BLOWFISH, ivlen=8, keysizemin=40, keysizemax=448
...
...
000 algorithm IKE encrypt: id=7, name=OAKLEY_AES_CBC, blocksize=16, keydeflen=128
000 algorithm IKE encrypt: id=5, name=OAKLEY_3DES_CBC, blocksize=8, keydeflen=192
000 algorithm IKE hash: id=2, name=OAKLEY_SHA, hashsize=20
...
...
000 "net-to-net":   IKE algorithms wanted: 5_000-1-5, 5_000-1-2, 5_000-2-5, 5_000-2-2, flags=-strict
000 "net-to-net":   IKE algorithms found:  5_192-1_128-5, 5_192-1_128-2, 5_192-2_160-5, 5_192-2_160-2, 
000 "net-to-net":   IKE algorithm newest: 3DES_CBC_192-MD5-MODP1536
000 "net-to-net":   ESP algorithms wanted: 3_000-1, 3_000-2, flags=-strict
000 "net-to-net":   ESP algorithms loaded: 3_000-1, 3_000-2, flags=-strict
000 "net-to-net":   ESP algorithm newest: 3DES_0-HMAC_MD5; pfsgroup=<Phase1>
...
...
000 #4: "net-to-net" STATE_QUICK_R2 (IPsec SA established); EVENT_SA_REPLACE in 3635s; newest IPSEC; eroute owner
000 #4: "net-to-net" [email protected] [email protected] [email protected] [email protected]
000 #12: "net-to-net" STATE_MAIN_R3 (sent MR3, ISAKMP SA established); EVENT_SA_REPLACE in 1153s; newest ISAKMP
[root@vpn2 tmp]#

It is important to know the status of your VPN as it can provide valuable troubleshooting clues when there are problems. This can be especially important when establishing a VPN between your Linux firewall and a non-Linux device. The IKE and ESP timers, and encryption, hash and key exchange algorithms must match at both ends to have success. This command allows you to see the value combinations Openswan is using and help you configure the VPN device on the other end to have compatible settings.

测试 VPN 连接

You can test the VPN connectivity by sending a simple ping from one private network to the other. In this case, the ping goes to the Windows server 10.0.0.105, which protected by vpn2, from server 172.16.1.1, which is protected by vpn1.

If the tunnel is up but ICMP pings don't work, then you need to check that the servers at both ends of the tunnel have routes pointing to the VPN firewalls. Also, check for additional network access controls between the servers and the VPN firewall. There may be additional firewalls in the way or the servers themselves may be running firewall software:

C:\>ping 10.0.0.105
 
Pinging 10.0.0.105 with 32 bytes of data:
 
Reply from 10.0.0.105: bytes=32 time=20ms TTL=253
Reply from 10.0.0.105: bytes=32 time<10ms TTL=253
Reply from 10.0.0.105: bytes=32 time=10ms TTL=253
Reply from 10.0.0.105: bytes=32 time<10ms TTL=253
 
Ping statistics for 10.0.0.105:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum =  20ms, Average =  7ms
 
C:\>

检查路由

You'll need to check the routes after the VPN tunnel is up as well. As you can, see there is an additional route to the 172.16.1.0 network on firewall vpn2. Incorrect routing on the firewalls can cause problems, check your leftnexthop and rightnexthop values in your /etc/ipsec.conf file.

[root@vpn2 tmp]# netstat -nr
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
10.0.0.0         0.0.0.0         255.255.255.0   U        40 0          0 eth1
6.25.232.0       0.0.0.0         255.255.255.248 U        40 0          0 eth0
172.16.1.0       97.158.253.25   255.255.255.0   UG       40 0          0 eth0
127.0.0.0       0.0.0.0         255.0.0.0       U        40 0          0 lo
0.0.0.0         6.25.232.6      0.0.0.0         UG       40 0          0 wlan0
[root@vpn2 tmp]#

使用 TCPdump

If the tunnel doesn't appear to become established, use the tcpdump command as explained in Chapter 4, "Simple Network Troubleshooting", to determine whether the traffic is being seen at both ends of the tunnel. You need to know whether the IPSec packets are even reaching your VPN firewall. Check routing and your Openswan configuration if not.

Protected Interface TCPDUMP Output From "vpn2"

Here the TCPdump is done on server2 where you see unencrypted ICMP ping traffic successfully passing back and forth between the two servers.

[root@vpn2 tmp]# tcpdump -n -i eth1 icmp
03:05:53.971308 IP 172.16.1.1 > 10.0.0.105: icmp 64: echo request seq 89
03:05:53.995297 IP 10.0.0.105 > 172.16.1.1: icmp 64: echo reply seq 89
03:05:54.972759 IP 172.16.1.1 > 10.0.0.105: icmp 64: echo request seq 90
03:05:54.972789 IP 10.0.0.105 > 172.16.1.1: icmp 64: echo reply seq 90
03:05:55.972985 IP 172.16.1.1 > 10.0.0.105: icmp 64: echo request seq 91
03:05:55.972999 IP 10.0.0.105 > 172.16.1.1: icmp 64: echo reply seq 91 
^C
[root@vpn2 tmp]#

Unprotected Interface TCPDUMP Output From "vpn2"

Here the encrypted ESP traffic is encapsulating the pings passing back and forth between the two VPN boxes. The true source and destination IP addresses (10.0.0.105 and 172.16.1.1) are hidden.

[root@vpn2 tmp]# tcpdump -n -i eth1  host 97.158.253.25
02:08:23.637149 IP 6.25.232.1 > 97.158.253.25: ESP(spi=0xf4909a7e,seq=0x73)
02:08:24.635302 IP 97.158.253.25 > 6.25.232.1: ESP(spi=0x808e9a87,seq=0x74)
02:08:24.637988 IP 6.25.232.1 > 97.158.253.25: ESP(spi=0xf4909a7e,seq=0x74)
02:08:25.638015 IP 97.158.253.25 > 6.25.232.1: ESP(spi=0x808e9a87,seq=0x75)
^C
[root@vpn2 tmp]#

检查系统日志中的错误信息

As always, check your /var/log/messages file for any messages that may provide clues as to the source of your problems.

"Invalid Key" 信息

If your left and right public keys were incorrectly applied to your /etc/ipsec.conf file or your regenerated keys were not updated in your /etc/ipsec.secrets file, then you will get messages stating that the keys are invalid and that information is being ignored.

003 "net-to-net" #1: ignoring informational payload, type INVALID_KEY_INFORMATION
003 "net-to-net" #1: received and ignored informational message
003 "net-to-net" #1: discarding duplicate packet; already STATE_MAIN_I3
031 "net-to-net" #1: max number of retransmissions (2) reached STATE_MAIN_I3.  Possible 
authentication failure: no acceptable response to our first encrypted message

总结

VPNs are increasingly becoming an everyday part of life on the Internet. Many people use them to gain access to many of the systems in their offices, such as e-mail and intranets. This trend is certain to become more popular as many companies are finding it cheaper for their employees to work from home, relieving them of the need to lease additional office space.

Site-to-site VPNs will also continue to be deployed as companies, both small and large find it increasingly necessary to share access to their business systems. One notable area is in the realm of IP telephony, where VPNs enable all remote offices to use a single IP switchboard at the center of a VPN hub and spoke network. Intra-office communication is therefore encrypted and the use of a single switchboard saves costs.

Knowledge of VPNs is now indispensable for systems administrators.