VPN column: PPTP(1)--connecting process

hu_hit原创,如需转载请注明出处。Thanks.

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

1. PPTP连接过程;

2. PPTP协议解析;

3. PPTP的路由。

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

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

VPN column: PPTP(1)--connecting process

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

一、建立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的控制层连接。

上一篇:python基础-------模块与包(一)


下一篇:hibernate的id生成策略