PPTPL2TP协议详解以及应用部署 - 图文(4)

值小，所以默认查不到明细路由的数据包都送到第一条默认路由进行处理。所以虚拟专用网络leadsec连接之后，远程用户不能再访问互联网地址，只能访问公司局域网

查看防火墙的路由变化，多了到目的网络10.10.10.2的出接口ppp0的明细路由

经过NAT的PPTP隧道

1.拓扑图

2.环境描述

分支机构通过出口FW1连接互联网，在出口FW1上作NAT，将172.16.1.0/24网段转换为出口FW1的外网口地址211.103.135.192，现在分支结构需要通过PPTP隧道连接到公司总部局域网。

3.配置

在公司总部出口FW2上添加两个远程拨号用户，并且开启PPTP服务 在出口FW1上作NAT转化，将172.16.1.0/24到any的流量源地址转化为211.103.135.192

分别在分支结构的两个客户端建立虚拟拨号连接，连接到211.103.135.192，具体的参数配置参考\不经过NAT的PPTP隧道\，这里不再详述了。接下来要分析的是PPTP穿越NAT的工作机制

PPTP穿越NAT的工作机制

我们知道GRE（请看GRE协议介绍）是没有端口信息的，并且它是跟TCP、UDP是同一层的，GRE的ip协议号是47，TCP的ip协议号是6，UDP的ip协议号是17。那GRE穿越NAT的时候怎么映射呢？这个时候你可能会想到那就只转换ip不就得了，但是这对防火墙是个问题。接下来我们就来分析下：如果处于分支机构的主机A172.16.1.2（NAT转换为211.103.135.192）与pptp服务器211.103.135.221建立连接，控制连接成功建立，数据连接由于没有端口，NAT只做其ip的转换，于是在出口FW1上有这样的一个NAT表：

SIP 172.16.1.2 172.16.1.2 SPort Proto 转换地址 转换端口 DIP DPort 5000 TCP 211.103.135.192 5001 GRE 192.168.1.2 192.168.1.2 1723 211.103.135.192 当211.103.135.192这个防火墙收到来自于pptp服务器211.103.135.221的数据流包时，211.103.135.192这个 nat设备发现来自于网络211.103.135.221的gre 协议数据包，是给分支结构的172.16.1.2主机的，所以成功通信。分析如果位于分支结构的172.16.1.3 也与211.103.135.221的pptp服务器通信，结果就不太理想了。因为如果在nat表中还有一条到达主机172.16.1.3的gre通信，到收到一个gre协议数据包时，211.103.135.192这个nat设备犹豫了，这个包给谁呢？172.16.1.2?还是172.16.1.3呢？在此大家也不要忘了，我们的实验环境是只有一个公网ip,分支结构的172.16.1.2和172.16.1.3出去的时候，源ip都转换成了公网的ip211.103.135.192，所以收到的数据包都是目标ip为211.103.135.192，然后nat设备根据端口的不同转发到不同的主机，但是又因为GRE根本就没有端口这一说法，所以有两个客户端就无法通信。 当然了，明知道PPTP穿越NAT的时候有问题，我们就要解决它，就好像IPSEC穿越NAT的时候，就需要在IPSEC包头前面额外的插上UDP。人们发现gre协议中有一个字段，可以拿来利用，那就是这个call id值，这个值并不固定，可以改变。这个值是怎么回事呢？用来标识唯一会话的。这个值最早出现在控制连接中，客户端与服务器互相通告彼此的call id值，然后在其数据连接中，服务器call id值写上客户端的，客户端写上服务器的call id值。所以我可以把call id值当做端口来看，然后添加到nat表中。下面来具体分析下call id和nat转化的关系了！！！ 分析客户端172.16.1.2到PPTP服务器211.103.135.221的PPP以及GRE数据报 172.16.1.2到211.103.135.221的Outgoing-Call-Request包中表明自己的call id为3277