Easy VPN 实验(5)

C 220.1.3.0/24 is directly connected, Serial1/2 S 192.168.10.0/24 [1/0] via 220.1.1.2 10.0.0.0/24 is subnetted, 1 subnets

C 10.1.1.0 is directly connected, FastEthernet0/0 S* 0.0.0.0/0 is directly connected, Serial1/2

在 网络扩展模式中应为不需要PAT，所以VPN连通后就相当与一个内部局域网，所以在show crypto ipsec client ezvpn结果中没有看到从服务器 端地址池中获取到的IP地址因为现在不需要了。那这个时候Server端如何访问Client端的网络呢，因为在Server端配置了Revers- route，Server上会自动创建指向Remote内部网络的静态路由。 接下来我们在Client端的PC上测试连通性。

C:\\Documents and Settings\\cx>ping 220.1.2.2 Pinging 220.1.2.2 with 32 bytes of data:

Reply from 220.1.2.2: bytes=32 time=149ms TTL=126 Reply from 220.1.2.2: bytes=32 time=124ms TTL=126 Reply from 220.1.2.2: bytes=32 time=127ms TTL=126 Reply from 220.1.2.2: bytes=32 time=149ms TTL=126 Ping statistics for 220.1.2.2:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds:

Minimum = 124ms, Maximum = 149ms, Average = 137ms C:\\Documents and Settings\\cx>ping 10.1.1.2 Pinging 10.1.1.2 with 32 bytes of data:

Reply from 220.1.1.1: Destination host unreachable. Reply from 220.1.1.1: Destination host unreachable. Reply from 220.1.1.1: Destination host unreachable. Reply from 220.1.1.1: Destination host unreachable. Ping statistics for 10.1.1.2:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds:

Minimum = 0ms, Maximum = 0ms, Average = 0ms

我们发现Client端PC能正常访问 Internet但不能通过VPN访问Server端内网。为什么呢？我们在PC机上跟踪一下数据包。

C:\\Documents and Settings\\cx>tracert 220.1.2.2

Tracing route to 220.1.2.2 over a maximum of 30 hops 1 88 ms 47 ms 46 ms 192.168.10.1 2 80 ms 100 ms 184 ms 220.1.1.1 3 72 ms 81 ms 236 ms 220.1.2.2 Trace complete.

C:\\Documents and Settings\\cx>tracert 10.1.1.2

Tracing route to 10.1.1.2 over a maximum of 30 hops 1 16 ms 27 ms 46 ms 192.168.10.1 2 132 ms 50 ms 70 ms 220.1.1.1

3 220.1.1.1 reports: Destination host unreachable. Trace complete.

通过跟踪发现他们出去的下一跳地址都是220.1.1.1，就是说数据包都没有经过VPN隧道传输，而是直接走了 PAT，通过在Client端show ip nat translation得以证明。 EZVPN-Client#show ip nat translations

Pro Inside global Inside local Outside local Outside global icmp 220.1.1.2:512 192.168.10.2:512 10.1.1.2:512 10.1.1.2:512 icmp 220.1.1.2:512 192.168.10.2:512 220.1.2.2:512 220.1.2.2:512

所 以能ping通Internet WEB就很正常了，但是ping 10.1.1.2的数据包由于被送到了ISP路由器，而ISP路由器上没有到达10.1.1.0网段的路由，所以返回目的地不可达的回应。那怎么解决这个 问题呢，可能这个时候我们想到那就用隧道分离不就可以了吗？那我们来试试看，首先在Server端加上隧道分离的命令，如下： access-list 100 permit ip 10.1.1.0 0.0.0.255 any crypto isakmp client configuration group test acl 100

接下来在Client端重新建立VPN连接并测试。 clear crypto session 清除原有的VPN连接

Mar 30 14:52:19.935: EZVPN(test-Client): Pending XAuth Request, Please enter the following command:

Mar 30 14:52:19.939: EZVPN: crypto ipsec client ezvpn xauth

因为启用了 XAUTH认证，所以在连接重置后要求重新输入用户名和密码 使用show crypto ipsec client ezvpn查看隧道建立是否成功是否启用了隧道分离 EZVPN-Client#show crypt ipsec client ezvpn Easy VPN Remote Phase: 4 Tunnel name : test-Client

Inside interface list: FastEthernet0/0 Outside interface: Serial1/2 Current State: IPSEC_ACTIVE Last Event: SOCKET_UP Default Domain: cisco.com Save Password: Disallowed Split Tunnel List: 1

Address : 10.1.1.0

Mask : 255.255.255.0 Protocol : 0x0 Source Port: 0 Dest Port : 0

Current EzVPN Peer: 220.1.3.2

我 们看见隧道分离建立成功，接下来在PC端测试。 C:\\Documents and Settings\\cx>ping 10.1.1.2 Pinging 10.1.1.2 with 32 bytes of data:

Reply from 220.1.1.1: Destination host unreachable. Reply from 220.1.1.1: Destination host unreachable. Reply from 220.1.1.1: Destination host unreachable.

Reply from 220.1.1.1: Destination host unreachable. Ping statistics for 10.1.1.2:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds:

Minimum = 0ms, Maximum = 0ms, Average = 0ms 测试结果还是目的不可达，为什么呢？这里我个人是这样理解的，首先我们在服务器和客户端上都启用了NAT功 能，当Easy VPN Client工作在Easy VPN Remote Client模式下时，EZVPN-Client会自动创建一个loopback口，当有用户需要访问EZVPN-Server后面的主机 时，EZVPN-Client会自动用loopback接口的地址做PAT，这个时候Easy VPN Client自动创建的PAT要优先于我们手动配置的NAT，当不匹配PAT时再匹配NAT，所以Client模式下默认EZVPN-Client端内网 的PC ping不通外网，因为所有的数据包都被送到隧道里面去了，并没有送到外网，所以当启用隧道分离后就能解决这个问题了。而当Easy VPN Client工作在Easy VPN Remote network-extension模式下时，EZVPN-Client不需要创建PAT，当VPN连通后就相当与一个内部局域网。这个时候在 EZVPN-Client端上只有一个我们手动配置的NAT，所以当数据包进入路由器的时候，还没有来得及把数据包送到隧道里面就先被NAT翻译出去了， 所以也就导致在这个模式下，能ping通外网WEB，但不能ping通对端内网的PC。这个时候即使我们在服务器上启用了隧道分离技术也没有用，因为数据 包先被NAT出去了。要解决这个问题我们只能在EZVPN-Client上更改NAT的配置，告诉NAT哪些数据包要NAT出去，哪些不要被NAT，并把 EZVPN-Server上有关隧道分离的命令删除，具体修改配置如下： EZVPN-Server端

no access-list 100 permit ip 10.1.1.0 0.0.0.255 any crypto isakmp client configuration group test no acl 100

EZVPN-Client端

no access-list 1 permit 192.168.10.0 0.0.0.255

no ip nat inside source list 1 interface serial 1/2 overload

access-list 111 deny ip 192.168.10.0 0.0.0.255 10.1.1.0 0.0.0.255 access-list 111 permit ip any any

ip nat inside source list 111 interface serial 1/2 overload 在Client端PC机上测试。

C:\\Documents and Settings\\cx>ping 10.1.1.2 Pinging 10.1.1.2 with 32 bytes of data:

Reply from 10.1.1.2: bytes=32 time=242ms TTL=124 Reply from 10.1.1.2: bytes=32 time=319ms TTL=124 Reply from 10.1.1.2: bytes=32 time=344ms TTL=124 Reply from 10.1.1.2: bytes=32 time=270ms TTL=124 Ping statistics for 10.1.1.2:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds:

Minimum = 242ms, Maximum = 344ms, Average = 293ms 从测试结果上来看是成功了，这个时候我们又开始考虑那在网络扩展模式加这种模式下，情况是这样，经过测试情况跟网络扩展模式下一样。所以这里就不在重复了。

百度搜索“77cn”或“免费范文网”即可找到本站免费阅读全部范文。收藏本站方便下次阅读，免费范文网，提供经典小说综合文库Easy VPN 实验(5)在线全文阅读。