转自：http://blog.csdn.net/zhu_hit/article/details/5698958

在未来几天会总结一下PPTP的工作过程，分为以下3篇讲述。

1. PPTP连接过程；

2. PPTP协议解析；

3. PPTP的路由。

由于我是工程经验先于理论学习，所以讲述过程也是先实现后理论，如果你没有网络工程经验的话可能会比较难看懂。

首先，我们从解析packets来讲述PPTP的连接过程。

下面按照发包的顺序解释连接过程：

一、建立TCP连接

1. Client端向PPTP Server的1723端口发TCP SYN包，请求建立TCP连接；

2. PPTP Server接受TCP连接请求，回SYN ACK；

二、建立PPTP控制层连接

3. PPTP Client发送Start Control Connection Request；(这里有一点需要注意：TCP的三次握手协议只运行了SYN和SYN ACK，在上面的协议实现中第三个ACK报不是单独发送的，而已经是带有效载荷的数据包了。实际很多实现都是这样做的，请不要死记书本上的“三次”握 手。)

4. PPTP Server回Start Control Connection Reply。在PPTP的这几个数据包都是基于TCP连接的，需要特别注意的是TCP Flag中的PUSH位都是被置成1的。那么，PUSH是干嘛的呀？PUSH被置1表示发送端要求接收端在收到该message后立即送到应用层，而不是 等到缓冲区满再发往应用层；

5. PPTP Client发Outgoing Call Request；

6. PPTP Server回Outgoing Call Reply。到此为止，PPTP的控制层连接就已经建立起来了。下面的相当一部分工作都是由PPP协议来完成的。另外还有一个需要注意的变化，如果你足够 细心的话，你会发现之后的packet是基于IP发送的，而不再是基于TCP了，其中的原因我们会在下一篇“PPTP协议解析”中解释。

三、PPP协议的LCP协商

7. 接下来我们看到，Client和Server互发了一大堆LCP包，这实际是PPP协议中的LCP(Link Control Protol)协议。LCP is used for estabishing, configuring and testing data-link connection. 其中有几点要注意：

(1) Client发送一个Configure-Request，把自己的link layer configure发给Server，Client端的Configure一般比较简单，所以Server一下子就接受了，立即回了一个 Configure-Ack；

(2) Server同时也必须发送一个Configure-Request，把自己的link layer configure发给Client，而这个configure包含的内容往往比较多；

(3) 如果Client收到的Configure-Request中，有unknow的配置项，就会把这些项列出来发一个Configure-Reject包给Server；

(4) Server端把Client不认识的配置项删掉，再次重发Configure-Request；

(5) 这次Client收到的配置项全都认识了，开始检查是不是所有的配置都可以接受，如果接受的话LCP过程结束，否则把不能接受的配置项列出来发送Configure-Nak给Server；

(6) Server再次修改配置项，再次发送Configure-Request；

(7) Client发现这次的配置项全都认识，而且全都是自己可以接受的，回发Configure-Ack。

(8) 到此为止，LCP就算完事了。其中如果有一个过程失败就会导致LCP协商失败。

8.  Client和Server接受彼此的配置之后，PPTP的控制层会彼此互发Set Link Info；

四、PPP协议的身份验证

9.  LCP协商完毕后，PPP协议的Server端会对Client端进行身份验证；

10. 可以选CHAP、MS-CHAP、MS-CHAP-v2...进行验证，具体选项我们会在解析PPP协议时讲述，现在以CHAP为例，需要注意到以下几点：

(1) Server发送Challenge，其中包括一个challenge string和server name；

(2) Client回Response，其中包括用户名，和密码和challeng string。其中用户名以明文发送(这个需要特别注意)，密码的challenge string经过单向hash算法后以密文形式发送；

(3) Server发送success，表示身份验证成功。

五、PPP协议的NCP协商

11. 身份验证通过后，PPP双方会进行NCP协商，用来确定互相通信的网络层接口参数；

12. 接下来你会看到一大堆IPCP协商数据包，它是NCP基于TCP/IP的接口协商协议。Server和Client都要把自己的Miniport信息发给对方，告诉对方我以后就用它和你通信了，你同不同意请给回个话。具体过程如下：

(1) Server把自己的Miniport信息通过Configure-Request发送给Client；

(2) Client也把自己的Miniport信息通过Configure-Request发送给Server；(这个时候Client发出的配置信息是完全无效的数据，之所以要故意发无效数据，是要求Server来给自己分配IP等信息)

(3) Client接受Server的接口配置，发送Configure-Ack；

(4) Server发现Client的配置是无效的，自己给Client发送一组有效的配置信息，通过Configure-Nak发送给Client，其中主要是给他分配IP；

(5) Client根据Server端发出的Configure-Nak，提取出给自己分配的IP、DNS等信息，并设置Miniport接口；

(6) Client根据修改后的配置，再次发送Configure-Request；

(7) Server接受Client的配置，发送Configure-Ack；

六、CCP是干嘛的

大家应该很少看到介绍CCP的资料，至少我是没看到过。它看起来像PPTP的Control Connection Protol的简写，但是是跑在PPP协议上的，所以应该和PPTP的控制层协议没有关系。我们发现在IPCP协商过程中穿插了很多CCP包，所以虽然少 见但最好还是解释一下它是干嘛的；

CCP中包括了MPPC和MPPE的参数协商，也就是Microsoft Point-to-Point Compression 和 Microsoft Point-to-Point Encryption的参数协商，用来确定数据包中的压缩和加密算法和参数。

七、GRE协议发送packets

13. 之后就是PPTP数据链路之间发送packets了，发送的是经过GRE封装过的PPP包。

八、PPTP链路维护

14. PPTP跑起来之后就是一大堆GRE包，但是每隔一段时间仍然会看到一些control message，是用来维护链路的；

15. 一端发送Echo-Request，注意是双方任意一端都可以发送该消息，不一定非得是Client或者Server。

16. 另一端收到Echo-Request之后必须返回Echo-Relpy。

17. 如果某一端在一段时间内不能收到Echo-Relpy，就会主动断开PPTP的控制层连接。