NAT和PPTP分析和总结.docxVIP

NAT 和 PPTP 我建了一个 PPTP 的帐号，想访问一下公司的内网资源，结果发现，没法传输数据，这是怎么回事？于是在 Google 里面输入 rfc pptp，直接就点进去了第一条带有 RFC 2637 的链接，开始了今天的穿越。。。。。。 问题出在哪里 首先稍微介绍一下，PPTP 有两个流，一个是控制流（RFC2637 定义），另外一个数据流（GRE，RFC2784）。和一般的 ALG 不同的是（比如 FTP），NAT 遇到 PPTP 的时候，不是端口或者 IP 惹的祸，而是 PPTP 里面邪恶的 callID（抛一个球给各位，为何PPTP 把 call ID 整到 PPTP 控制流里面？)。在PPTP 协议里面，有一个 call ID 的概念，客户端向服务器发起连接，会告诉服务端我的 call ID 是多少，服务端也会回应客户端它的 call ID 是多少，并且更重要的一点是，这个call ID 在以后的某些（注意不是全部哦）控制传输中需要用到，在所有的数据传输中（GRE）需要用到。而接下来我们从两个方面一起来看一下问题是如何产生，以及如何去解决： 从内网向外网发起 PPTP 连接请求 从外网向内网发起 PPTP 连接请求（俗称静态映射） 走，咱们去看看外面的世界 （注：下面的结构是 1）提一下 PPTP 协议；2）提一下 GRE 协议；3）如何搞定 GRE 数据流；4）如何搞定 PPTP 控制流。） PPTP 服务器是监听在 TCP/1723 端口。客户端发送的第一个携带 call ID 的数据包是被称为 Outgoing-Call-Request 的数据包，一个示例如下图所示（忽略了前面的以太网头，IP 头，以及 TCP 头）： 可以看到我们这边的示例客户端的 call ID 是 16384（这个 call ID 是给自己分配的），那我就以 Client-Call-ID 表示吧。 服务端收到这个数据包之后，然后会回应一个称为 Outgoing-Call-Reply 的数据包，示例如下： 这个说明服务端自己的 call ID 是 107（这个服务端是给自己分配的，我就以Server-Call-ID 表示）， 同时也把 Client-Call-ID 返回给客户端。咦，这样看来好像没有什么问题嘛，反正这个call ID 改不改，对于这一条连接都没有影响，NAT 也可以正常运作。但是，各位看官，PPTP 还需要用到一个协议，那就是GRE（RFC 2784）。而 GRE 是一个和 TCP 以及 UDP 处在同一个水平线的协议。但是和 TCP/UDP 之流不同的是，GRE 里面不携带端口信息，而它利用的就是 call ID 来作 multiplex 以及 demultiplex 的。我们看一下客户端发给服务端的一个 GRE 数据包（提示一点，GRE 头后面的是 PPP 协议封装，不过这里不需要关心）： 里面有 call ID，这个 call ID 不是说自己的，而是说对方的（对，就是 PPTP 里面的那个 Server-Call-ID），也就是服务端的，也就是我这个 GRE 数据要发给服务端的 107“端口”。 而服务端也采用同样的策略，只不过 call ID 表明的是客户端的，一个示例如下： （注：上面的都是一些协议的原理，如果你读了RFC，未必不懂这些。插一个情景，来自一个电影：C 开一辆车在公路上，前面有一个人 D 骑一辆自行车。C 在追 D 的，C 紧张的说：“你。。。你骑自行车未必比我开车快！”） 问题是这些个数据包也要经过我们可怜的 NAT 啊，GRE 会问 NAT：“我这个call ID，管还是不管？”，NAT 答曰：”不管。”话虽如此，但是谈何容易，因为 GRE 里面没有端口，如果 NAT 不伪造一个端口的话，下面的情形就不堪设想了： 一个主机 A 的 IP 地址是 ，向 （声明：这里仅仅是假设，没有对其进行真正的试验， 请不要见怪）发起 PPTP 连接请求，Client-Call-ID 是 16384，Server-Call-ID 是 107； 还有一个主机 B 在内网，IP 地址是 ，也向 发起 PPTP 连接请求，Client-Call-ID2 是 16385， Server-Call-ID2 是 108。 NAT 如果仅仅是转换 IP 地址（假设 NAT 的公网 IP 是 59），那么数据到能够到达 ，可是 GRE 数据包回到 59 的时候，NAT 这个时候是该把它发给 呢，还是 呢？在这种情况下， NAT 必须要找一个“端口”，来决定这个数据包是发给谁，而“端口”需要满足以下特性： 在一台主机上，这个是唯一的； 必须每个数据包中都存在。 而扫描整个 GRE 数据包，只有call ID 具有此特