PPTP VPN在Cisco Router上的应用二：PPTP扩展实验

浏览数：135 / 时间：2015年06月20日

本文继续上一篇关于PPTP VPN的实验。

拓扑图依旧使用上次的拓扑，配置不变。读者需要在上一篇博文的基础上来阅读本文。

拓扑图如下：

本博文关于PPTP的实验包括以下内容：

实验1：基本的PPTP Server配置和Client配置（WinXP和Win7）

实验2：使用不加密的PPTP配置

实验3：使用PAP或CHAP认证的PPTP配置

实验4：PPTP问题1：TCP1723被阻止导致无法拨通

实验5：GRE防火墙检测和PAT转换问题

实验6：综合实验1：PPTP在实际工程的应用

实验7：综合实验2：PPTP结合radius实现多用户部署

实验2：使用不加密的PPTP配置

Router的配置：

R1#sh run int virtual-template 1

interface Virtual-Template1

ip unnumbered Loopback0

peer default ip address pool vpn-address-pool

ppp encrypt mppe auto

ppp authentication ms-chap ms-chap-v2

end

通过路由器的配置可以看到在使用MPPE加密，但后而的关键字是auto，即可以加密也可以不加密。如此的话，我们不需要更改路由器的配置，更改客户端的配置为不加密即可。当然，这里也可以选择强制加密或者强制不加密。

客户端配置如下：（由于现在大多数电脑都是Win7操作系统，因此后续实验都以Win7为例，不再演示XP的配置。）

只需要在这里将默认的“需要加密（如果服务器拒绝将断开连接）”改为上图中红框中的两个之中即可，不同之处于在和路由器的协商。之后即成功拨通VPN了。

实验3：使用PAP或CHAP认证的PPTP配置

路由器配置：

R1(config)#int virtual-template 1

R1(config-if)#ppp authentication chap

将路由器上关于PPTP认为方式的配置更改为CHAP

在WIN7上不需要进行配置修改，直接拨号即可。可以看到WIN7默认是支持CHAP认证的，但默认不支持PAP谁，需要手工修改。如果使用PAP认证，需要将路由器的认证方式改为PAP，并在WIN7客户端上勾选“未加密的密码（PAP）”这个选项。

修改路由器配置后拨VPN，无论是CHAP还是PAP，均成功拨通。

注意：这里读者需要注意的是，如果不是在初验的基础上就直接做实验3的话是不成功的。也就是说，当使用MPPE加密的时候，认为方式只能是MS-CHAP和MS-CHAPV2；当不使用加密的时候，也可以使用PAP和CHAP认证。

实验4：PPTP问题1：TCP1723被阻止导致无法拨通

在上一篇博文中笔者已经提到了PPTP的控制层面和数据层面是分开的，控制层面使用的是TCP的1723端口。因此，如果TCP 1723端口无法访问，会导致PPTP拨号不上去。

该实验继续在上面的配置下进行。首先测试PPTP拨号正常，然后在R2路由器上写一条阻止TCP 1723端口的ACL，再次拨号，发现Client可以ping通R1,却无法拨号上去。

R2增加配置如下：

R2(config)#access-list 100 deny tcp any any eq 1723

R2(config)#access-list 100 permit ip any any

R2(config-if)#ip access-group 100 in

出现报错，但报错反映的内容不一定准确。因此还需要进行排错，以下贴出我的两种报错。前者是VPN类型为“自动”时的报错，后者是手动选为“PPTP”时的报错。这一类问题一般出现在防火墙上，PPTP服务器在防火墙身后，当外网用户拨入的时候，防火墙只放行了GRE的流量，没有放行TCP 1723端口。

实验5：PPTP问题2：GRE防火墙检测和PAT转换问题

在放行了TCP1723端口后，还有常遇到的问题就是GRE的问题。GRE的问题有2个：

GRE防火墙检测
PAT转换问题

防火墙会对TCP、UDP、ICMP等流量进行状态化检测，只有在状态化表项中有的条目才会放行，但不同厂商的防火墙对GRE的流量默认不一定检测，可能需要手工开启或ACL放行。

我们更改一下拓扑图，将R2换成一台简单的防火墙。（在这里可以使用Cisco的ASA模拟器来模拟防火墙，或使用Cisco的Zone-Based Firewall，在这里我们将R2换成一台ASA防火墙进行模拟该实验。）

ASA Version:8.4

ASA配置如下：

ciscoasa(config)# int g0

ciscoasa(config-if)# nameif outside

INFO: Security level for "outside" set to 0 by default.

ciscoasa(config-if)# security-level 0

ciscoasa(config-if)# ip add 12.1.1.2 255.255.255.0

ciscoasa(config-if)# no shut

ciscoasa(config-if)# int g1

ciscoasa(config-if)# nameif inside

INFO: Security level for "inside" set to 100 by default.

ciscoasa(config-if)# security-level 100

ciscoasa(config-if)# ip add 23.1.1.2 255.255.255.0

ciscoasa(config-if)# no shut

ciscoasa(config)# policy-map global_policy

ciscoasa(config-pmap)# class inspection_default

ciscoasa(config-pmap-c)# inspect icmp

使用win7进行VPN拨号，发现刚刚可以拨通的VPN现在不能拨通了。

使用telnet 来测试 12.1.1.1的1723端口发现没有问题。

在Win7上ping12.1.1.1也可以ping通。

这就是GRE导致的问题了，基于状态化的防火墙会在数据包出去的时候检测会话，并进行记录，当数据包回来的时候如果表项中有这一条记录，则放行，如果没有，则数据被Deny掉。但默认的情况下，思科的防火墙ASA没有对GRE的流量进行状态化检测，导致数据包无法返回。解决的办法有2个：1是检测GRE的流量，2是在outside接口放行回来的GRE流量。

方法一：Inspect PPTP

ciscoasa(config)# policy-map global_policy

ciscoasa(config-pmap)# class inspection_default

ciscoasa(config-pmap-c)# inspect pptp

再次拨号，成功，并能ping通R1身后的内网。